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 <
artem.zinnatul...@gmail.com> 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 <krsc...@gmail.com> 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 <techie....@gmail.com>
>>>> 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 <
>>>>>> artem.zi...@gmail.com> 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 adt-dev+u...@googlegroups.com.
>>>>>>> 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 adt-dev+u...@googlegroups.com.
>>>>> 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 adt-dev+u...@googlegroups.com.
>>> 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 adt-dev+unsubscr...@googlegroups.com.
> 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 adt-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
