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

[Doug Schaefer <cdtdoug@xxxxxxxxx>]

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