Send andmore-dev mailing list submissions to
andmore-dev@xxxxxxxxxxx
To subscribe or unsubscribe via the World Wide Web, visit
https://dev.eclipse.org/mailman/listinfo/andmore-dev
or, via email, send a message with subject or body 'help' to
andmore-dev-request@xxxxxxxxxxx
You can reach the person managing the list at
andmore-dev-owner@xxxxxxxxxxx
When replying, please edit your Subject line so it is more specific
than "Re: Contents of andmore-dev digest..."
Today's Topics:
1. Re: How out of date is Andmore (David Carver)
2. Re: How out of date is Andmore (Doug Schaefer)
----------------------------------------------------------------------
Message: 1
Date: Wed, 20 Jan 2016 10:10:30 -0500
From: David Carver <kingargyle@xxxxxxxxx>
To: andmore-dev@xxxxxxxxxxx
Subject: Re: [andmore-dev] How out of date is Andmore
Message-ID: <569FA366.10600@xxxxxxxxx>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
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
<mailto: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 <mailto: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 <mailto: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 <mailto: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://dev.eclipse.org/mailman/private/andmore-dev/attachments/20160120/b6fcc47e/attachment.html>
------------------------------
Message: 2
Date: Wed, 20 Jan 2016 10:17:46 -0500
From: Doug Schaefer <cdtdoug@xxxxxxxxx>
To: andmore developer discussions <andmore-dev@xxxxxxxxxxx>
Subject: Re: [andmore-dev] How out of date is Andmore
Message-ID:
<CAMACn2Hjg4s6ZP1L_4JedXHETuuyrncMs-2TOF4TOgqBvaKC5w@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="utf-8"
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>
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>
http://tools.android.com
Please do not send me questions directly. Thanks!
_______________________________________________
andmore-dev mailing listandmore-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://dev.eclipse.org/mailman/private/andmore-dev/attachments/20160120/92f0c410/attachment.html>
------------------------------
_______________________________________________
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
End of andmore-dev Digest, Vol 12, Issue 13
*******************************************
