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]. For more options, visit https://groups.google.com/d/optout.
