Gradle 1.0

[Matthias]

I'm sure you all noticed that Gradle is approaching its 1.0 release quickly (it's at milestone release 4 now).

I was therefore wondering how you feel about 1.0 vs 0.9 support, since there are a few things I am working on right now that will be deprecated with 1.0, and are even broken in 0.9.

Personally I am very eager to have flawless and seamless Eclipse support with your Android Gradle builds, since it's the official IDE of choice for Android.

However, the Eclipse Groovy DSL has been completely revamped for 1.0, and it also a fixes an important bug that keeps me from baking Android Library project support into our EclipseEnhancement. The problem is that 0.9's EclipseProject task generated a wrong tag for linked resources (links instead of linkedResources, see http://issues.gradle.org/browse/GRADLE-1482), which mean it's impossible with 0.9 to mimic the project setup the ADT generate when adding a reference to a library project (which is creating a workspace link to its src folder).

I have successfully built a sample app with Gradle 1.0-milestone-4 and the latest Android plugin, therefore I was thinking if we should people required to use the plugin with Gradle 1.0? Otherwise I'd have to create the enhancement twice, once using old, once using the new syntax, and well, it wouldn't even work correctly with Gradle 0.9.

Thoughts?

[Matthias]

actually I just noticed that Ladislav had already been working on Gradle 1.0 support. Perhaps a good alternative would be to merge back all fixes we did on master into that branch, and I continue working on library support by branching off of the gradle-1.0m2-support branch?

• gradle-1.0m2-support ✓

• gradle-1.0m2-support ✓

[Matthias]

Two things I noticed after merging master into 1.0-support:

1) integration tests are failing, although I don't know whether they were actually passing on master (can't tell without re-installing Gradle 0.9, since compilation fails with 1.0)

2) the Android project in the test resource folder ends up being added to the Eclipse classpath. Is that necessary? It doesn't compile because it can't find the Android JAR. I think we should not add it to the Eclipse classpath in the first place

[Ladislav Thon]

Asked about this some time before and I think we reached a consensus that until Gradle 1.0 final is released, we should support 0.9. I still think that noone really uses Gradle 0.9 now, it's way too old.

I did some work to support Gradle 1.0 milestones (mainly to fix the build because of some changes), but stopped at 1.0-m2. m3 and m4 brings some more incompatible changes (e.g., GradleLauncher was deprecated).

 

1) integration tests are failing, although I don't know whether they were actually passing on master (can't tell without re-installing Gradle 0.9, since compilation fails with 1.0)

Well, they were at least when I committed them :-) I'll have a look.

 

2) the Android project in the test resource folder ends up being added to the Eclipse classpath. Is that necessary? It doesn't compile because it can't find the Android JAR. I think we should not add it to the Eclipse classpath in the first place

Yes. I actually didn't try to generate IDE project files for Gradle Android Plugin by Gradle, so I didn't step into this, but you're right that src/integTest/resources/androidProjects shouldn't be treated as Java sources of Gradle Android Plugin.

LT

[Matthias]

well we're actually still using 0.9 at work, but I see not problem in switching to a pre-1.0 version if the project still builds. Looking at the integration tests, I must say this looks great! Haven't had to chance to play with it, but I like the way you set it up. As for the test failure, it's a NPE that's thrown somewhere down the call stack, see here: http://pastebin.com/CcG9Mzdw

[Ladislav Thon]

Looking at the integration tests, I must say this looks great! Haven't had to chance to play with it, but I like the way you set it up.

Thanks :-) I especially love the thing that the test projects are also (almost) self-contained examples. 

[Matthias Käppler]

Exactly!

--
sent on the run, from my precious nexus one. (it rhymes!)

[Ladislav Thon]

So, I've got the integration tests fixed (sadly, I can't use Tooling API to launch the builds yet, so instead I hacked the way I call GradleLauncher). But I see you did some changes in gradle-1.0m2-support branch -- are those really 1.0-milestone-2 compatible, or are we declaring gradle-1.0m2-support branch as simply "gradle-1.0-support"? Just to make sure where should I commit my fixes.

LT

[Matthias Käppler]

it should be gradle-1.0-support, that's what we're opting for after
all. I tested against the m4 release.

2011/7/31 Ladislav Thon <lad...@gmail.com>:

--
-Matthias

[Ladislav Thon]

it should be gradle-1.0-support, that's what we're opting for after
all. I tested against the m4 release.

Agreed. Let's just say that the name is bad and the branch should be for 1.0-related development, that is, it should currently support 1.0-m4.

LT

[Ladislav Thon]

Okay, pushed.

LT

[Matthias Käppler]

Thanks!

Say, I have a question about Gradle's new artifact cache. Maybe you
can help. So formerly one was able to wipe the cache simply by
removing folders for a given package name in .gradle/cache. That
doesn't seem to be possible anymore, since not it's way more
complicated with Gradle taking SHAs of the cached artifacts and stuff.

The problem is that I am changing a library I am working on
frequently, but of course I don't bump the artifact version with every
build. That means however that depending projects don't see the
changes, since they think the JAR they're seeing is up to date. Do you
have any idea how to address that?

2011/7/31 Ladislav Thon <lad...@gmail.com>:
> Okay, pushed.
>
> LT

--
-Matthias

[Ladislav Thon]

The problem is that I am changing a library I am working on
frequently, but of course I don't bump the artifact version with every
build. That means however that depending projects don't see the
changes, since they think the JAR they're seeing is up to date. Do you
have any idea how to address that?

Don't know anything about this, but maybe this can help: http://issues.gradle.org/browse/GRADLE-629 See the last two comments especially.

LT 

[Fabio Da Soghe]

Hello everybody.

I missed this conversation: I was unable to read email yesterday.

For what I remember, we sticked to Gradle 0.9 because we thought the 1.0 release was not so far... today I agree to concentrate on 1.0 compatibility and move on the old installations of 0.9 (I still am using 0.9 but it's not a problem to do the upgrade: endeed I was already thinking about it).

If you have no complaints about my little fix on Proguard support (branch proguard-work), I'll merge it into master today.

Cheers,

Fabio

2011/7/31 Ladislav Thon <lad...@gmail.com>

[Jason Voegele]

On Aug 1, 2011, at 4:04 AM, Fabio Da Soghe wrote:
> Hello everybody.
>
> I missed this conversation: I was unable to read email yesterday.
> For what I remember, we sticked to Gradle 0.9 because we thought the 1.0 release was not so far... today I agree to concentrate on 1.0 compatibility and move on the old installations of 0.9 (I still am using 0.9 but it's not a problem to do the upgrade: endeed I was already thinking about it).
>
> If you have no complaints about my little fix on Proguard support (branch proguard-work), I'll merge it into master today.

Hi Fabio,

Sorry, I haven't yet had a chance to test your changes from the proguard-work branch. The one thing I'd like to verify is that Scala builds still work with the patch, because I vaguely recall some previous work I did on ProGuard happened to break Scala builds.

--
Jason Voegele
"Out of register space (ugh)"
-- vi

[Ladislav Thon]

Sorry, I haven't yet had a chance to test your changes from the proguard-work branch. The one thing I'd like to verify is that Scala builds still work with the patch, because I vaguely recall some previous work I did on ProGuard happened to break Scala builds.

The integration test suite contains one extremely simple Scala project -- not sure if it is sufficient, but it should catch the most obvious errors.

On a related subject -- I'd love to have an instrumentation testing project in the test suite, I even have a test project ready (I recall that I posted it on our users mailing list some time before as an example), but it requires starting an Android emulator from the test. There is an androidStartEmulator task now (or is it androidEmulatorStart? Not sure) and there was some work on making the task wait until the emulator is properly started, so maybe it will become possible in near future. Having that Scala test project also run in emulator would be great to make us sure we didn't break Scala support. Just an idea.

LT

[Fabio Da Soghe]

2011/8/1 Jason Voegele <jason....@gmail.com>

I'm sorry but I'm not easily able to test a scala project, I haven't the devel environment needed (besides the tests already present into the project, as Ladislav says) and I'm completely dummy on the subject.

I can say the modification I did is very trivial. Besides some log message (at info level), the patch is this (in file /src/main/groovy/com/jvoegele/gradle/tasks/android/ProGuard.groovy):

-      libraryjar(file: ant['android.jar']) 
- 
+      ant.references['android.target.classpath'].each { targetjar -> 
+        libraryjar(file: targetjar) 
+      } 
+ 

I remember you encountered problems with Scala projects, but I can't imagine a way this patch could break something (but Murphy's law is always there...)

Fabio

[Matthias]

I was wondering if we should merge all Gradle 1.0 related work into master now and continue from there?

It looks like we all work with the 1.0-m4 branch (and branches that branch off that one), but there's a few things that made it into the plugin 1.0 release that are not yet in the Gradle 1.0 specific branches. We could cherrypick them, but honestly I see no reason why we shouldn't start working on master, considering that we agreed that the next release should have full support for Gradle 1.0.

Thoughts?

[Jason Voegele]

Agreed. Let's merge all work related to Gradle 1.0 support into master and proceed from there.

--
Jason Voegele
Common sense and a sense of humor are the same thing, moving at
different speeds. A sense of humor is just common sense, dancing.
-- Clive James

[Matthias Käppler]

done.

Please everyone continue your work on master.

My changes include mostly fixes to EclipseEnhancement:

 * migrate to Gradle 1.0 Eclipse DSL

 * rudimentary support for handling dependencies to Android library projects; specifically, the eclipseClasspath task will create an Eclipse source link to library projects declared in default.properties. This requires the library project to be on the normal Gradle build path as an artifact dependency. When building with Gradle, the JAR from that dependency will be used to find the library classes; when building in Eclipse, it will compile the library sources straight into your app and ignore the Gradle dependency (therefore mimicking standard ADT behavior). This behavior will work well for build servers, where the library sources are unlikely to exist next to the app project. Downside is that currently the plugin assumes that library artifact name and library project folder have the same name.

 * several fixes to Eclipse classpath generation

I believe Ladislav also worked on integration tests. Speaking of which: I now get compilation errors in Eclipse for the HelloActivity; it can't find the Android classes. Can you look into that if you have a minute Ladislav?

Cheers for moving this forward!

-Matthias

2011/8/26 Jason Voegele <jason....@gmail.com>

--
-Matthias

[Matthias Käppler]

done.

Please everyone continue work on master.

My changes include mostly fixes to EclipseEnhancement:

 * migrate to Gradle 1.0 Eclipse DSL

 * rudimentary support for handling dependencies to Android library projects; specifically, the eclipseClasspath task will create an Eclipse source link to library projects declared in default.properties. This requires the library project to be on the normal Gradle build path as an artifact dependency. When building with Gradle, the JAR from that dependency will be used to find the library classes; when building in Eclipse, it will compile the library sources straight into your app and ignore the Gradle dependency (therefore mimicking standard ADT behavior). This behavior will work well for build servers, where the library sources are unlikely to exist next to the app project. Downside is that currently the plugin assumes that library artifact name and library project folder have the same name.

 * several fixes to Eclipse classpath generation

I believe Ladislav also worked on integration tests. Speaking of which: I now get compilation errors in Eclipse for the HelloActivity; it can't find the Android classes. Can you look into that if you have a minute Ladislav?

Ch

[Ladislav Thon]

I believe Ladislav also worked on integration tests. Speaking of which: I now get compilation errors in Eclipse for the HelloActivity; it can't find the Android classes. Can you look into that if you have a minute Ladislav?

I'll try to have a look at it, but I currently don't have much time. I didn't even managed to review the code for Groovy support yet -- and the pull request is about a week old I think! (Guys, if you are reading this -- sorry, I'll try to get to it soon, but I can't give any promises. If anyone else steps into this, I would be glad.)

LT

[Ladislav Thon]

I believe Ladislav also worked on integration tests. Speaking of which: I now get compilation errors in Eclipse for the HelloActivity; it can't find the Android classes. Can you look into that if you have a minute Ladislav?

Got some time and looking into this now. I see I remembered it wrong -- I thought it doesn't compile using Gradle, which it does perfectly fine for me (gradle clean devBuild passes OK).

I'm not sure about the structure of your Eclipse project -- I use IntelliJ IDEA for Gradle Android Plugin development and I don't set the integration tests projects as real source code of the plugin, they're just some random resources. I create special projects for them, so that nothing clashes.

Also, now that master is for Gradle 1.0, I think we should delete the 1.0-support branch. I'll do it soon if noone objects. And one question: what is this libsupport-1.0 branch? I think that we have the 1.0.x branch for future releases in 1.0 line (should there be any), but libsupport-1.0?

LT

[Matthias Käppler]

Hi,

libsupport is fully merged into both the 1.0 branch and master. Feel free to delete.

Yes I use Eclipse, and using the project setup generated from gradle eclipse, the project doesn't compile. If I have time I'll investigate what's happening there.

--
sent on the run, from my precious nexus one. (it rhymes!)

[Ladislav Thon]

libsupport is fully merged into both the 1.0 branch and master. Feel free to delete.

OK, thanks.

Yes I use Eclipse, and using the project setup generated from gradle eclipse, the project doesn't compile. If I have time I'll investigate what's happening there.

Well, if we run `gradle eclipse` on our Gradle Android Plugin, it should definitely produce a compilable Eclipse project :-) I'll try to look at it, but I'm not familliar with the Gradle way of producing Eclipse's (or IDEA's) project files.

LT