You can build different types of your dependencies to binary artefacts and
include different versions in main project using product flavored
dependency (or buildType)
For example:
main_project build.gradle:
android {
productFlavors {
flavor1
flavor2
}
}
dependencies {
flavor1Compile 'dependencyVersionForFlavor1'
flavor2Compile 'dependencyVersionForFlavor2'
}
But as I know library projects don't support product flavors
On Wednesday, February 18, 2015 at 9:02:25 PM UTC+3, Greg Macdonald wrote:
>
> Thanks, Artem
>
> That makes sense and surely it is a good use case.
>
> In our case, we need all modules to be built with the same build variant.
> It makes more sense to me that dependencies included as pre-built artifacts
> will come in as release built modules, but for sub-projects that are built
> as part of building the app, it makes sense that this is code also under
> development and when I want the app to be built with a particular build
> target and flavor, I should have the option of this being applied to those
> modules also. The fact that it does not work this way by default is odd to
> me. I'm pretty sure that other IDE's I've used for different compiled
> languages all work this way.
>
> thanks,
> greg
>
> On Wed, Feb 18, 2015 at 8:39 AM, Artem Zinnatullin <[email protected]
> <javascript:>> wrote:
>
>> Greg, I am really sorry for my first reply to your post, please accept my
>> apologies :(
>>
>> It's design of Gradle: build of one project should not affect build state
>> of other projects involved in build process.
>>
>> Library subproject should not know about build params of main project,
>> because you should be able to replace it as already built artefact.
>>
>> But you can try to share some pieces of Gradle configuration between
>> projects, for example you can declare some variables in root build.gradle
>> like this: project.ext { someVar }
>> and then read it in subproject: project.someVar, it can help with flavor
>> specific build config fields
>>
>> On Wednesday, February 11, 2015 at 9:22:56 PM UTC+3, Greg Macdonald wrote:
>>>
>>> Kevin, what do your numbers 1-5 relate to? esp. 3 & 4
>>>
>>> >>...can't necessarily flow the variants up to the libraries...
>>>
>>> No, you cannot at all affect the build of sub-projects. Everything but
>>> your main app project are built as release. So, for example, referencing
>>> BuildConfig.DEBUG from code gives a different answer from the app project
>>> than from a subordinate library project.
>>>
>>> On Wed, Feb 11, 2015 at 6:11 AM, Kevin Schultz <[email protected]>
>>> wrote:
>>>
>>>> I don't understand these points at all.
>>>>
>>>> 1) You can maintain Eclipse & AS support at the same time. Back when AS
>>>> was actually unstable and Eclipse was actually more useful, I maintained
>>>> both ant & gradle support in our project so that our team could use
>>>> either.
>>>> Keep the source structure as Eclipse expects it, and change the sourceSets
>>>> in the gradle config to match. There are examples of this online.
>>>>
>>>> Of course, you will quickly find that all the power of Gradle is lost
>>>> if you handcuff yourself to only features that also work under Ant. I made
>>>> it such that you could build a debug build with Ant, but if you wanted the
>>>> other build types, you had to use Gradle. That allowed the team to
>>>> continue
>>>> using the tools they wanted while we experimented with AS. Note that this
>>>> was fall of 2013. Our team of 5 Android developers switched relatively
>>>> soon
>>>> their after, and we haven't looked back. I personally use the canary
>>>> channel of AS, and I may have lost 2 business days to tools problems, out
>>>> of hundreds and hundreds of days. The productivity gain has more than made
>>>> up for it. New features may have issues, but generally speaking we're
>>>> talking about issues with feature that didn't exist in Eclipse + ADT
>>>> anyway, and that doesn't stop you from getting your work done as you had
>>>> before.
>>>>
>>>> There are very narrow use cases where AS doesn't have the support you
>>>> need, but outside of native code the argument that "Android Studio is not
>>>> ready for prime time" doesn't hold any water.
>>>>
>>>> 2) Most libraries will work - with the exception of AAR - in Eclipse.
>>>> However, I can tell you most of the people writing libs are using the
>>>> modern tools.
>>>>
>>>> 3) Yes
>>>>
>>>> 4) ?
>>>>
>>>> 5) Module support under AS is way better than under Eclipse. It's
>>>> trivial to add Java or Android library modules to the project and it works
>>>> quite well. I have split my app into a few different modules and I'm quite
>>>> happy with it. You can't necessarily flow the variants up to the
>>>> libraries,
>>>> but there wasn't even a mechanism for something like build variants in
>>>> Ant,
>>>> so I'm not sure I see how that is a knock on Gradle.
>>>>
>>>>
>>>> On Wednesday, February 11, 2015 at 1:10:34 AM UTC-5, Greg Macdonald
>>>> wrote:
>>>>>
>>>>> Thanks, Kiran. We've a long term Android guy on our team who is
>>>>> experienced with eclipse & ant and our project is yet small; but, yes,
>>>>> I'm
>>>>> concerned about switching and I sure don't want to get stuck in an
>>>>> old-tools world once AS is working well enough and moving forward.
>>>>>
>>>>> So, what I hear from you in balance is:
>>>>> - if one goes back, we all go together
>>>>> - 3rd party libs may not be maintaining support for eclipse-centered
>>>>> tools
>>>>> - ADT support for eclipse may wane (yea, in keeping with comments by
>>>>> ADT lead)
>>>>> - Binary repos (I'm thinking this isn't a big deal, isn't maven under
>>>>> jcenter anyway?)
>>>>>
>>>>> BTW, we are also considering turning the project into one monolithic
>>>>> project for now and breaking it up into sub-projects again when the tools
>>>>> support it better, but it's hard to maintain discipline around
>>>>> hierarchical
>>>>> order and separation in such a world. Alas and alack.
>>>>>
>>>>> Thanks again, Kiran
>>>>>
>>>>>
>>>>> On Tue, Feb 10, 2015 at 8:17 PM, Kiran Rao <[email protected]>
>>>>> wrote:
>>>>>
>>>>>> @Greg,
>>>>>>
>>>>>> I think reverting is more difficult because you will have to do
>>>>>> everything manually. While there is a migration path (and tooling
>>>>>> support)
>>>>>> for "converting" your project from Eclipse to Android Studio, there is
>>>>>> no
>>>>>> support for the opposite.
>>>>>>
>>>>>> You will find documentation on how you can make some adjustments to
>>>>>> the sourceSets in build.gradle such that the same project can be worked
>>>>>> on
>>>>>> from both AS and Eclipse + ADT - however in practice this doesn't work
>>>>>> well
>>>>>> (and I have tried this on a team of only two developers!)
>>>>>>
>>>>>> I have also found that of late, most open source libraries use the
>>>>>> AS/Gradle structure. You could of course grab the dependencies as
>>>>>> binaries,
>>>>>> or better, use Maven with your Eclipse/ADT setup. But then again,
>>>>>> several
>>>>>> libraries are distributed as AARs and last time I checked, Eclipse/ADT
>>>>>> had
>>>>>> trouble consuming AARs (at least Eclipse/ADT without Maven plugins did).
>>>>>>
>>>>>> What I'm trying to arrive at is that reverting to Eclipse might imply
>>>>>> reduced support going forward - both from the Tools team as well as from
>>>>>> the community.
>>>>>>
>>>>>> On Wednesday, 11 February 2015 06:56:18 UTC+5:30, Greg Macdonald
>>>>>> wrote:
>>>>>>>
>>>>>>> OK, I should add to 'factual', input that is useful. I'm really not
>>>>>>> interested in religious wars or 'tude.
>>>>>>>
>>>>>>> On Tue, Feb 10, 2015 at 5:20 PM, Artem Zinnatullin <
>>>>>>> [email protected]> wrote:
>>>>>>>
>>>>>>>> nano + javac is better choice for your team.
>>>>>>>>
>>>>>>>> For what reason you want to use flavors in not app modules? Seems
>>>>>>>> to be architect/design problem.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> P.S.
>>>>>>>>
>>>>>>>> Gradle is stable, working build tool, Android Gradle Plugin and
>>>>>>>> Android Studio are stable too, just fix dependecies versions. I
>>>>>>>> started to
>>>>>>>> use them from first public releases and I even changed 3 companies
>>>>>>>> after
>>>>>>>> this.
>>>>>>>>
>>>>>>>>
>>>>>>>> I just can't understand why people use Ant in 2015, okay, you don't
>>>>>>>> want to use Gradle, but there is Maven. It's just unwillingness to
>>>>>>>> learn
>>>>>>>> new things, and in my opinion — it's unprofessional.
>>>>>>>>
>>>>>>>> Learning new should not be hard, it should be fun and useful for
>>>>>>>> yourself.
>>>>>>>>
>>>>>>>> Just start with small personal project with Android Studio and
>>>>>>>> Gradle, when you'll feel comfortable with them, try to switch work
>>>>>>>> project
>>>>>>>> to Gradle + AS.
>>>>>>>>
>>>>>>>> --
>>>>>>>> You received this message because you are subscribed to the Google
>>>>>>>> Groups "adt-dev" group.
>>>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>>>> send an email to [email protected].
>>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>> You received this message because you are subscribed to the Google
>>>>>> Groups "adt-dev" group.
>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>> send an email to [email protected].
>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>
>>>>>
>>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "adt-dev" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to [email protected].
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>> --
>> You received this message because you are subscribed to the Google Groups
>> "adt-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected] <javascript:>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
--
You received this message because you are subscribed to the Google Groups
"adt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
