Re: [andmore-dev] How out of date is Andmore

[David Carver <kingargyle@xxxxxxxxx>]

I did some searching and this should help a bit:

https://android.googlesource.com/platform/tools/build/+/master/gradle-model/src/test/java/com/android/build/gradle/model/AndroidProjectTest.java

https://android.googlesource.com/platform/tools/build/+/master/gradle/src/main/groovy/com/android/build/gradle

Source code and any tests are going to be the best documentation.

Dave

On 1/20/16 10:17 AM, Doug Schaefer wrote:

Thanks Dave,

Maybe it's still too early in the day and I haven't finished my first coffee yet, but I haven't seen in any of those bugs nor a quick Googling around what the actual Android model is. Is this something I can figure out going directly to the Gradle Tooling APIs?

On Wed, Jan 20, 2016 at 10:10 AM, David Carver <kingargyle@xxxxxxxxx> wrote:

There are a couple of bugs that have been filed:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=468315

https://bugs.eclipse.org/bugs/show_bug.cgi?id=468244

The Andmore bug:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=459572

Dave

On 1/19/16 4:01 PM, Xavier Ducrohet wrote:

Gradle provide a tooling API to run it, but also to query the project model. Our model returns all the information needed to configure the classpath.

However our model is custom and different from the regular java model (which actually isn't standard, there's a built-in one for Eclipse and a built-in one for IJ). What you need is an extension point in Buildship to allow querying the Android model and then some custom code to go through it and setup the project's classpath.

The mountain of code you've inherited makes certain assumption (location of manifest file, source folders, res folders, etc...) that doesn't work with Gradle. All that info is in the Android model though.

I agree that starting with loading Gradle file, having JDT configured (classpath) and a bit of work to deploy APKs built by Gradle would be the first step to do.

On Tue, Jan 19, 2016 at 12:34 PM, Doug Schaefer <cdtdoug@xxxxxxxxx> wrote:

Thanks Dave. Do we have a bug number for the Gradle issue. I'm trying to wrap my head around what they'd provide that we'd use.

My thinking if I was to do it over again would be to start minimalistic. With my CDT mindset, I'd call command line tools to do as much as we possibly can with them. Clearly we can call gradle from the command line, i.e. Runtime.exec(). And we can somewhat guess at what jars to add to the classpath based on the output of that build. And I wouldn't necessarily try to reuse the class files the JDT produces in the gradle build. With gradle running as a daemon, I imagine builds would be fast enough, at least to start.

Lots of things to think about. I fear the mountains of code that we've inherited and I'm not even certain it works when upstream doesn't seem to work. And we don't have a lot of people jumping in to volunteer to get us there. Tough problem.

On Tue, Jan 19, 2016 at 9:10 AM, David Carver <kingargyle@xxxxxxxxx> wrote:

Doug touched on most of these, so I'm just going to answer a couple in line.

On 1/17/16 12:18 PM, Thomas Golden wrote:

As an Android developer who has reluctantly moved to Gradle+Android Studio, here's what I think are table stakes for an Eclipse-based solution:

1. Acknowledge that for better or worse, the Gradle build system has won. Any Andmore solution should be capable of importing an Android Gradle project successfully. This probably means doing a lot of work on Eclipse's Gradle support, which is shoddy the last time I looked. This also means things like build variants and flavors.

2. As part of 1, ensure that AAR dependencies are first-class citizens. Eclipse/ADT can't handle them at all. The android-maven plugin team did some great work making it function from the command line but it's useless if it can't be done in the IDE. A lot of useful libraries (RxAndroid and RxBindings, Play Services, etc) are distributed as AARs, not JARs.

Yes, these are top priorities, but the problem from my end has been finding the time necessary to start working on it.   Also, there are still hooks we need from the Eclipse Gradle  team for us too capture some of this information.  Regardless we do need the AAR container support which can be done separetely to at least allow the Maven Tooling to work with it.  m2e android stuff works fairly well, but AAR support is also one of their most requested features as well.

3. Also related to 1, ensure that Andmore can build multidex projects. ADT was totally incapable of doing this, meaning I had to build and deploy from the command line, and attach a debugger after the fact. This KILLS momentum during development. In a perfect world multidex wouldn't be necessary, but it is.

Multi-dex support was recently added by a community memember.  I think you have to go into the project settings, and enable it directly for a particular project.  If it isn't working then it needs a bug report so it can be investigated eventually.

Some nice-to-haves:
* Eclipse/ADT had some hard-coded language levels that prevented the use of Retrolambda to use Java 8 syntax in projects - even if it was configured in your build properly, the IDE just would not let you set the source level to 8 and flagged all instances of those syntax features as compile errors.
* Steal shamelessly some of the editor features Android Studio has such as showing the actual String value of R.string ints in the editor.

You should be able to specify Java 8 as an api level.  I think I removed most of those restrictions a while ago.  However, I haven't tested it or the dexing support when these are enabled.  The default is Java 1.7, at least until the android dexers support java 8 and those libraries come from the AOSP.

_______________________________________________
andmore-dev mailing list
andmore-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/andmore-dev

_______________________________________________
andmore-dev mailing list
andmore-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/andmore-dev

--

Xavier Ducrohet
Android SDK Tech Lead
Google Inc.
http://developer.android.com | http://tools.android.com

Please do not send me questions directly. Thanks!

_______________________________________________
andmore-dev mailing list
andmore-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/andmore-dev

_______________________________________________
andmore-dev mailing list
andmore-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/andmore-dev

_______________________________________________
andmore-dev mailing list
andmore-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/andmore-dev