Version 0.3 of the gradle plugin is out

[Xavier Ducrohet]

System requirements
Gradle 1.3+ (tested on 1.3/1.4)
Android Platform Tools 16.0.2+

New Features
Renderscript support.
Support for multi resource folders. See 'multires' sample (PNG crunch is now done incrementally and in parallel.)
Support for multi asset folders.
Support for asset folders in Library Projects.
Support for versionName suffix provided by the BuildType.

Testing
Default sourceset for tests now src/instrumentTest (instrumentTest<Name> for flavors)
Instrumentation tests now:
  - started from "deviceCheck" instead of "check"
  - run on all connected devices in parallel.
  - break the build if any test fails.
  - generate an HTML report for each flavor/project, but also aggregated.
New plugin 'android-reporting' to aggregate android test results across projects. See 'flavorlib' sample.

Improved DSL
Replaced android.target with android.compileSdkVersion to make it less confusing with targetSdkVersion
Signing information now a SigningConfig object reusable across BuildType and ProductFlavor
Ability to relocate a full sourceSet. See 'migrated' sample.
API to manipulate Build Variants.

Fixes
Default Java compile target set to 1.6.
Fix generation of R classes in case libraries share same package name as the app project.

Documentation
New documentation: http://tools.android.com/tech-docs/new-build-system/user-guide
This should make it easier to get started.

Also new samples showing some of the new features are available.

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

Please do not send me questions directly. Thanks!

[Xavier Ducrohet]

"compileSdkVersion = 17" is actually valid.

On Tue, Feb 26, 2013 at 10:52 AM, rciovati <rcio...@gmail.com> wrote:

Thanks Xavier, this is really appreciated.

A little remark about the documentation: in the first example there is "compileSdkVersion = 17" where it should be "compileSdkVersion 17". 

Best Regards,

Riccardo

--
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 adt-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[rciovati]

Il giorno martedì 26 febbraio 2013 20:10:39 UTC+1, Xavier Ducrohet ha scritto:

"compileSdkVersion = 17" is actually valid.

For me is giving this error:

Host:basic rciovati$ gradle clean assembleDebug
:clean
:prepareDebugDependencies
:compileDebugAidl FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':compileDebugAidl'.
> Unknown target: 17

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

BUILD FAILED

Total time: 6.315 secs

while using "compileSdkVersion 17" works as expected.

Best regards.

[Xavier Ducrohet]

that's weird.

the error is not tied to the syntax though, as the error message would be different.

I'm wondering if it uses the wrong setter. There's one that receives an int and one that receives a string.

The former converts it to string with "android-%d" while the latter uses it as is.

I'll do some tests. thanks for the report.

--

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 adt-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[rciovati]

Il giorno martedì 26 febbraio 2013 20:46:38 UTC+1, Xavier Ducrohet ha scritto:

I'll do some tests. thanks for the report.

If it can help you I made a little investigation today.
I tried putting a logging statement inside the DefaultSdkParser.resolveTarget method and looks like that the target variable contains just "17" so probably it is using the wrong setter.

Best Regards.

[Xavier Ducrohet]

Yeah I just finished looking into it.

The extension object contains the following methods:

compileSdkVersion(int)

compileSdkVersion(String)

setCompileSdkVersion(int)

setCompileSdkVersion(String)

compileSdkVersion 15 => compileSdkVersion(int)

compileSdkVersion "android-15" => compileSdkVersion(String)

compileSdkVersion = 15 => setCompileSdkVersion(String)

compileSdkVersion = "android-15" => setCompileSdkVersion(String)

I'll file a bug on Gradle.

--

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 adt-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Joe Bowbeer]

Thanks!

As a smoke test, I built a few of the samples in NetBeans and installed and ran the tictactoe sample.  No problems so far, which a significant improvement over 0.2.

Environment:

Windows 7

Java 7

Gradle 1.4

NetBeans 7.3

Gradle NB plugin 1.2.0

Android SDK Tools 21.1; Platform-tools 16.0.2

[Xavier Ducrohet]

You can do

android {

    sourceSets {

        flavor2.setRoot('foo/flavor2')

    }

}

You cannot change the root of all flavors in a single pass though.

see http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Configuring-the-Structure

On Wed, Feb 27, 2013 at 8:52 AM, Sony Tricoire <sony.t...@gmail.com> wrote:

Hi,

So happy to play with this 0.3 version, great job !

I'm currently playing with a project mixing migration (i.e not complying wht src/main/java directories) and flavors.
The documentation say that :

• android.sourceSets.flavor1
  Location src/flavor1/
• android.sourceSets.flavor2
  Location src/flavor2/

Can I override or change the root sources diretory of my flavors ?

Thx

--

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 adt-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Xavier Ducrohet]

yes, feel free to send them on this list, thanks.

On Wed, Feb 27, 2013 at 1:46 PM, Benjamin Cooley <stard...@gmail.com> wrote:

Awesome! I've been working with 1.3-SNAPSHOT for a few weeks now (since I kept running into gradle bugs on Gradle version < 1.3)

I've actually been keeping a list of feedback/comments on issues I ran into, is this list the correct place to send it? (After I make sure they are still relevant to 1.3 of course).  If not, where should that be directed?

(They are mostly small, but there is a big one about errors getting eaten if you have a non-default Android.xml)

Congrats on the 1.3 release!

On Tuesday, February 26, 2013 10:03:08 AM UTC-8, Xavier Ducrohet wrote:

--

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 adt-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Manfred Moser]

Thanks for also making the library available in the Central Repository at

http://search.maven.org/#search%7Cga%7C1%7Cg%3A%22com.android.tools.build%22

Looking at the jar for the builder I find that there are a whole bunch
of libraries wrapped inside it including Android specific things like
ddmlib but also others like kxml2 and apache commons stuff.

Is this intentional? And what are the details of these classes? E.g.
is the ddmlib code in there equivalent to ddmlib of sdk v 21.0.1 or
so? And if that is the case .. can I assume that to be pretty stable
and e.g. use it now in the Android Maven Plugin.

I would e,g. like to replace the ddmlib from r17 of the sdk with the
codebase in the builder. Is that a good idea since I get the newer
ddmlib code or a bad one since it is modified heavily and beta quality
at best?

I would love to hear your thoughts and advice on adopting the library.

manfred

[Xavier Ducrohet]

it's a version of ddmlib that was in our tree at the moment we released 0.3.

When the gradle plugin becomes final, we'll actually synchronize it around the ddmlib (and other) libraries and they'll depend on actual versions that match SDK Tools release.

But right now the gradle plugin releases are whenever-it's-good-enough so it's hard to make it depend on an final ddmlib push.

The rest of the stuff in there (kxml, bunch of apache libraries) is mostly because it was somewhat easier to just package all the dependencies together than doing it selectively. I should fix this.

[Xavier Ducrohet]

You should not apply the java plugin.

On Thu, Feb 28, 2013 at 7:44 AM, Ilídio Varandas <vara...@gmail.com> wrote:

Hi,

Thanks for this new version of the plugin, and the improved documentation :)

I'm migrating from the 0.2 version but it's throwing an error when gradling the follow:

apply plugin: 'java'

buildscript {

    repositories {

        mavenCentral()

    }

    dependencies {

        classpath 'com.android.tools.build:gradle:0.3'

    }

}

repositories {

    mavenCentral()

}

apply plugin: 'android'

android {

    compileSdkVersion 16

    sourceSets {

        main {

            manifest.srcFile 'AndroidManifest.xml'

            java.srcDirs = ['src']

            res.srcDirs = ['res']

        }

        instrumentTest.setRoot('test')

    }

}

 

15:40:49.037 [ERROR] [org.gradle.BuildExceptionReporter] FAILURE: Build failed with an exception.

15:40:49.039 [ERROR] [org.gradle.BuildExceptionReporter] 

15:40:49.040 [ERROR] [org.gradle.BuildExceptionReporter] * What went wrong:

15:40:49.040 [ERROR] [org.gradle.BuildExceptionReporter] Cannot add task ':processTestResources' as a task with that name already exists.

15:40:49.043 [ERROR] [org.gradle.BuildExceptionReporter] 

15:40:49.044 [ERROR] [org.gradle.BuildExceptionReporter] * Exception is:

15:40:49.045 [ERROR] [org.gradle.BuildExceptionReporter] org.gradle.listener.ListenerNotificationException: Failed to notify project evaluation listener.

15:40:49.046 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.listener.BroadcastDispatch.dispatch(BroadcastDispatch.java:90)

15:40:49.046 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.listener.BroadcastDispatch.dispatch(BroadcastDispatch.java:30)

15:40:49.047 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.messaging.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)

15:40:49.048 [ERROR] [org.gradle.BuildExceptionReporter] at $Proxy10.afterEvaluate(Unknown Source)

15:40:49.049 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.configuration.LifecycleProjectEvaluator.evaluate(LifecycleProjectEvaluator.java:47)

15:40:49.049 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.api.internal.project.AbstractProject.evaluate(AbstractProject.java:466)

15:40:49.050 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.api.internal.project.AbstractProject.evaluate(AbstractProject.java:77)

15:40:49.051 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.configuration.ProjectEvaluationConfigurer.execute(ProjectEvaluationConfigurer.java:23)

15:40:49.051 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.configuration.ProjectEvaluationConfigurer.execute(ProjectEvaluationConfigurer.java:21)

15:40:49.052 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.api.internal.Actions$CompositeAction.execute(Actions.java:78)

15:40:49.053 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.api.internal.Actions$TransformingActionAdapter.execute(Actions.java:130)

15:40:49.053 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.api.internal.project.AbstractProject.configure(AbstractProject.java:442)

15:40:49.054 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.api.internal.project.AbstractProject.allprojects(AbstractProject.java:437)

15:40:49.055 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.configuration.DefaultBuildConfigurer.configure(DefaultBuildConfigurer.java:40)

15:40:49.055 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.initialization.DefaultGradleLauncher.doBuildStages(DefaultGradleLauncher.java:142)

15:40:49.056 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.initialization.DefaultGradleLauncher.doBuild(DefaultGradleLauncher.java:113)

15:40:49.057 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.initialization.DefaultGradleLauncher.run(DefaultGradleLauncher.java:81)

15:40:49.057 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.launcher.cli.ExecuteBuildAction.run(ExecuteBuildAction.java:38)

15:40:49.058 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.launcher.exec.InProcessGradleLauncherActionExecuter.execute(InProcessGradleLauncherActionExecuter.java:39)

15:40:49.059 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.launcher.exec.InProcessGradleLauncherActionExecuter.execute(InProcessGradleLauncherActionExecuter.java:25)

15:40:49.059 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.launcher.cli.RunBuildAction.run(RunBuildAction.java:50)

15:40:49.060 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.api.internal.Actions$RunnableActionAdapter.execute(Actions.java:171)

15:40:49.061 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.execute(CommandLineActionFactory.java:201)

15:40:49.061 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.execute(CommandLineActionFactory.java:174)

15:40:49.062 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:170)

15:40:49.063 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:139)

15:40:49.064 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:33)

15:40:49.064 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:22)

15:40:49.065 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.launcher.Main.doAction(Main.java:48)

15:40:49.066 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.launcher.bootstrap.EntryPoint.run(EntryPoint.java:45)

15:40:49.067 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.launcher.Main.main(Main.java:39)

15:40:49.067 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.launcher.bootstrap.ProcessBootstrap.runNoExit(ProcessBootstrap.java:50)

15:40:49.068 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.launcher.bootstrap.ProcessBootstrap.run(ProcessBootstrap.java:32)

15:40:49.069 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.launcher.GradleMain.main(GradleMain.java:26)

15:40:49.070 [ERROR] [org.gradle.BuildExceptionReporter] Caused by: org.gradle.api.InvalidUserDataException: Cannot add task ':processTestResources' as a task with that name already exists.

15:40:49.070 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.api.internal.tasks.DefaultTaskContainer.add(DefaultTaskContainer.java:61)

15:40:49.071 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.api.internal.tasks.DefaultTaskContainer.add(DefaultTaskContainer.java:76)

15:40:49.086 [ERROR] [org.gradle.BuildExceptionReporter] at com.android.build.gradle.BasePlugin.createProcessResTask(BasePlugin.groovy:464)

15:40:49.087 [ERROR] [org.gradle.BuildExceptionReporter] at com.android.build.gradle.BasePlugin.createProcessResTask(BasePlugin.groovy:460)

15:40:49.087 [ERROR] [org.gradle.BuildExceptionReporter] at com.android.build.gradle.BasePlugin.createTestTasks(BasePlugin.groovy:669)

15:40:49.088 [ERROR] [org.gradle.BuildExceptionReporter] at com.android.build.gradle.AppPlugin.createTasksForDefaultBuild(AppPlugin.groovy:385)

15:40:49.089 [ERROR] [org.gradle.BuildExceptionReporter] at com.android.build.gradle.AppPlugin.doCreateAndroidTasks(AppPlugin.groovy:204)

15:40:49.089 [ERROR] [org.gradle.BuildExceptionReporter] at com.android.build.gradle.BasePlugin.createAndroidTasks(BasePlugin.groovy:182)

15:40:49.090 [ERROR] [org.gradle.BuildExceptionReporter] at com.android.build.gradle.BasePlugin$_apply_closure1.doCall(BasePlugin.groovy:152)

15:40:49.091 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.listener.ClosureBackedMethodInvocationDispatch.dispatch(ClosureBackedMethodInvocationDispatch.java:40)

15:40:49.091 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.listener.ClosureBackedMethodInvocationDispatch.dispatch(ClosureBackedMethodInvocationDispatch.java:25)

15:40:49.092 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.listener.BroadcastDispatch.dispatch(BroadcastDispatch.java:81)

15:40:49.093 [ERROR] [org.gradle.BuildExceptionReporter] ... 33 more

Thanks

--

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 adt-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Xavier Ducrohet]

BTW, I've just updated the doc to mention this.

[Benjamin Cooley]

0.3 Feedback, in order of severity
I discovered most of these on 0.3-SNAPSHOT (from ~3 weeks ago), but I've verified they all still exist in the 0.3 release

1. Dex warnings fail build
• Dex warnings (such as "warning: Ignoring InnerClasses attribute for anonymous inner class that doesn't come with an EnclosingMethod attribute) will cause the build to fail, and are reported from gradle as an error. Should likely be reported as a warning and not cause build to fail?
• To Reproduce: Include a org.mortbay.jetty dependency (the old one, before they moved to eclipse. I think I was using 6.1.22) to an android build. I eventually just gave up trying to get it to work and had the code using that updated to using the newer version, but it was code that worked under eclipse adt so it probably should work under gradle.
  
2. Build Script Errors before android{} section are eaten when you have an alternative location for android.xml
• Any error in your build script that happens between the include android plugin section and where you tell android to use your new android.xml results in an error about android.xml missing instead of the underlying error.
• Easy way to reproduce: apply plugin: 'android'; throw new GradleException(); android { ... };, where in android you have a (correct) manifest{srcFile "AndroidManifest.xml"} and have a root level AndroidManifest.xml
  
• Workaround: Create a fake android.xml at the default location, this will cause the underlying error to be shown. Alternatively make sure to set manifest first immediately after you load the plugin.
  
3. Eclipse Settings:
• The eclipse plugin currently defaults to creating empty classpath/project files. My understanding is the plan is to (eventually) have tight IDE integration, which is great, but shouldn't it default to something sensible until then? It only takes ~7 lines to configure the plugin to produce the standard eclipse adt .classpath files, but it seems it would be better for the android plugin to default to this than have each project using the android plugin set it. (I can post the code if needed)
  
• While on the topic of sensible defaults, it looks like android projects (not library) don't register their apk's as publishable artifacts. Is there a reason for this?  While there are not (too) many projects that would want to consume an APK, a distribution project (that maybe zips up multiple apk's into a single file for download) might?
  
4. Parent Level Tasks?
• Most of the android tasks are dynamically created, which means its hard to hook other tasks into them (like if you had a common-before-compile task, or even just common code for all flavors).  Seems to me it would make sense to have each of the taskName$(flavor) tasks depend on an empty taskName task, so someone who wanted 'compileDebug' and 'compileRelease' to depend a 'myCodeGenerator' task, they could simply do compile.dependsOn(myCodeGenerator)
  

1 and 2 were obstacles to get around, 3 and 4 are more style/use suggestions :).

I had a few others, but it looks like they got fixed from my snapshot to the release, so yay =)

- Ben

[Xavier Ducrohet]

I will look into this.

On Sun, Mar 3, 2013 at 4:58 AM, Zulaxia S <zul...@gmail.com> wrote:

I've just started moving to Gradle with the 0.3 milestone, and have successfully moved compilation of my projects in an evening, where ant simply couldn't do it, so I'm very happy. My library projects all daisychain in dependency, and I'm pleased to say this just worked out of the box with this system.

That said, I've hit one show stopper issue, and have yet to work around it, and that's with assets merging.

With this in the build.gradle:

 sourceSets {

        main {

           assets.srcDirs =['assets']

        }

there are no assets in the final apk. I have tracked down the issue to the fact that the final packaging of assets may not use the 'main' sourceSet, unlike the other resource types. This can be seen in the build/incremental/mergeAssets/release/ folder. The inputs.data file correctly lists all the assets to be merged:

# incremental data. DO NOT EDIT.

# format is <lastModified> <length> <SHA-1> <path>

# Encoding is UTF-8

1361653692000 109500 ceff2c2a2e96d20fa98d11e8cfab4ca5cf7fe9fb /var/opt/eclipse/android_workspace/rift_stb/assets/font/AlbertusRU.ttf

1361743020000 918528 a5089ebe65f65b5790b6653aa9cac3e9f2c1f6eb /var/opt/eclipse/android_workspace/rift_stb/assets/db/souldata-en

1361743109000 1166336 e54126aa5be000293dcd24594d76fef9fc0bf041 /var/opt/eclipse/android_workspace/rift_stb/assets/db/souldata-fr

1361653692000 127176 7a82977a11f82fd5c61b22cb0a6a76b44b1ea746 /var/opt/eclipse/android_workspace/rift_stb/assets/font/RiftSans-Regular.ttf

1361743065000 1117184 33cdfabef544636f3f79e8212ed377ca8114f710 /var/opt/eclipse/android_workspace/rift_stb/assets/db/souldata-de

 however merger.xml contains the following:

<dataSet config="main">

  <source path="/var/opt/eclipse/android_workspace/rift_stb/assets"/>

</dataSet>

<dataSet config="release">

  <source path="/var/opt/eclipse/android_workspace/rift_stb/src/release/assets"/>

</dataSet>

Which then seemingly results in no assets being copied over for the 'release' type. 

That said, setting release.assets.srcDirs =['assets'] in the build.gradle correctly alters the release line of merger.xml, but outputs.data still remains empty, as does the assets folder of the final apk.

Is this misconfiguration on my part, or is this not working?

--
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 adt-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Xavier Ducrohet]

Hi Ben,

On Fri, Mar 1, 2013 at 4:00 PM, Benjamin Cooley <stard...@gmail.com> wrote:

0.3 Feedback, in order of severity
I discovered most of these on 0.3-SNAPSHOT (from ~3 weeks ago), but I've verified they all still exist in the 0.3 release

1. Dex warnings fail build
• Dex warnings (such as "warning: Ignoring InnerClasses attribute for anonymous inner class that doesn't come with an EnclosingMethod attribute) will cause the build to fail, and are reported from gradle as an error. Should likely be reported as a warning and not cause build to fail?

hmm yes. I should look into this.

 

• To Reproduce: Include a org.mortbay.jetty dependency (the old one, before they moved to eclipse. I think I was using 6.1.22) to an android build. I eventually just gave up trying to get it to work and had the code using that updated to using the newer version, but it was code that worked under eclipse adt so it probably should work under gradle.
  
1. Build Script Errors before android{} section are eaten when you have an alternative location for android.xml
• Any error in your build script that happens between the include android plugin section and where you tell android to use your new android.xml results in an error about android.xml missing instead of the underlying error.
• Easy way to reproduce: apply plugin: 'android'; throw new GradleException(); android { ... };, where in android you have a (correct) manifest{srcFile "AndroidManifest.xml"} and have a root level AndroidManifest.xml
  
• Workaround: Create a fake android.xml at the default location, this will cause the underlying error to be shown. Alternatively make sure to set manifest first immediately after you load the plugin.
  

Ah that's very interesting. I've seen this happen (or something very close to it) and filed a bug (http://issues.gradle.org/browse/GRADLE-2617) but I stopped being able to reproduce it. I'll double check on m side and update the bug for the gradle guys to look into it. 

1. Eclipse Settings:
• The eclipse plugin currently defaults to creating empty classpath/project files. My understanding is the plan is to (eventually) have tight IDE integration, which is great, but shouldn't it default to something sensible until then? It only takes ~7 lines to configure the plugin to produce the standard eclipse adt .classpath files, but it seems it would be better for the android plugin to default to this than have each project using the android plugin set it. (I can post the code if needed)
  

yes we could do something here but our goal is really to have a native integration. Even using the gradle plugin for eclipse is not going to be enough for things like handling resources in the editors, since Gradle introduces some new features that are not supported in ADT (multi-res folder for instance)

I'm interested in the code anyway, thanks!

 

• While on the topic of sensible defaults, it looks like android projects (not library) don't register their apk's as publishable artifacts. Is there a reason for this?  While there are not (too) many projects that would want to consume an APK, a distribution project (that maybe zips up multiple apk's into a single file for download) might?
  

Yeah that's a good point. I'll add it.

 

1. Parent Level Tasks?
• Most of the android tasks are dynamically created, which means its hard to hook other tasks into them (like if you had a common-before-compile task, or even just common code for all flavors).  Seems to me it would make sense to have each of the taskName$(flavor) tasks depend on an empty taskName task, so someone who wanted 'compileDebug' and 'compileRelease' to depend a 'myCodeGenerator' task, they could simply do compile.dependsOn(myCodeGenerator)
  

Wouldn't the output of your code generator be added to the input of compile tasks of all the variants though?

You're still going to have to loop through the variants to set this up since dependsOn() is not setting this up.

For the common code to all flavors you could just use src/main/java, but if you are sharing code between 2 out of n flavors you could put that code another folder somewhere and set it as another folder:

android.sourceSets.flavor1.srcDir 'shared/src1'

android.sourceSets.flavor2.srcDir 'shared/src1'

android.sourceSets.flavor3.srcDir 'shared/src2'

etc...

[Zulaxia]

Thanks,

I've made a more general solution now that I've added build flavours to my build script:

task copyAssetsHack {

group = BasePlugin.BUILD_GROUP

description = 'Hack to copy assets in release apk'

android.buildVariants.each { dest ->

copy {

from ('assets')

into "build/assets/"+dest.dirName

}

}

}

tasks.whenTaskAdded { task ->

    if (task.name.startsWith('merge') && task.name.endsWith('Assets')) {

        copyAssetsHack.dependsOn task

    }

    if (task.name.startsWith('compile')) {

task.dependsOn copyAssetsHack

    }

}

It does have the drawback of always copying all the assets for all flavours, but it gets the apks made.

--
You received this message because you are subscribed to a topic in the Google Groups "adt-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/adt-dev/sA8KFsquss4/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to adt-dev+u...@googlegroups.com.

[Xavier Ducrohet]

So I looked into it and it seems my implementation didn't take subfolders into account...

I have a pending fix for it. I may release an update just for this shortly. I'll let you know.

xavier

[Zulaxia]

Ah, easy enough to overlook, given the lack of folder depth elsewhere.

Thanks, and look forward to an update. Where's the best place to watch for notification of that?

[Xavier Ducrohet]

https://android-review.googlesource.com/#/q/status:open+project:platform/tools/build,n,z

[Ilídio Varandas]

Hi,

Having the same issue as Ben with the:

warning: Ignoring InnerClasses attribute for an anonymous inner class

...

Process output to error stream but exitCode is 0

:dexDebug FAILED

Terça-feira, 26 de Fevereiro de 2013 18:03:08 UTC, Xavier Ducrohet escreveu:

[Benjamin Cooley]

On eclipse: Sorry, I didn't really make it clear how I was trying to use it. I see how making eclipse work with all of the Gradle plugins new features would be hard.

I was more interested in the use-case of getting Gradle working with an existing eclipse build. The documentation is very detailed on how to configure gradle to use an old project structure, but as soon as you try to take advantage of gradle's powerful dependency management system, you run into a roadblock, how do you let eclipse developers reference downloaded jars when they are stored in caches?

Gradle handles this with the auto-generated .project and .classpath files.  Sadly though, android projects produce empty files :(.  Luckily, it only takes a few lines of configuration to produce files that work with eclipse.  This is why I thought it would be good thing to put into the plugin itself: Its small, a much more sensible default than nothing, covers a pretty common usecase (projects that are halfway between the current and new builds). 

Here is the code I am using to allow gradle and adt build to co-exist. This is my non-NDK version (NDK is a bit more complex):

            eclipse {
                classpath {
                    plusConfigurations += project.configurations.compile
                    containers 'com.android.ide.eclipse.adt.ANDROID_FRAMEWORK', 'com.android.ide.eclipse.adt.LIBRARIES'
                    //This line would be better than manually specify source folder, but doesn't work since Android sourceSets do not inherit from java sourcesets
                    //sourceSets = android.sourceSetsContainer
                    file {
                        withXml {
                            def node = it.asNode()
                            node.appendNode('classpathentry kind="src" path="src"')
                            node.appendNode('classpathentry kind="src" path="gen"')
                        }
                    }
                }
                project {
                    natures 'com.android.ide.eclipse.adt.AndroidNature'
                    buildCommands.putAt(0, new BuildCommand('com.android.ide.eclipse.adt.ResourceManagerBuilder'))
                    buildCommands.putAt(1, new BuildCommand('com.android.ide.eclipse.adt.PreCompilerBuilder'))
                    buildCommand 'com.android.ide.eclipse.adt.ApkBuilder'
                }
            }

Or, if you don't want to put something like this in the plugin, maybe in the documentation section about how to get the build system working with your current eclipse build? ;)

Anyway, Just my 2 cents :)

- Ben

[Xavier Ducrohet]

I see you have gotten some answers on the Gradle forums but I want to expand on it a bit.

First, the move to instrumentTest instead of test in 0.3 is to support things like this. I wanted to make it clear that the "test" task was not a normal test like in the Java plugin, so it was better to replace it. Same reason why it's anchored to the deviceCheck task instead of the check task.

Now, we should be automate this type of unit test somehow to deal with flavors I think. I'm not sure we'll add built-in support for roboelectric but I'd certainly like to make this easy for someone to built a roboelectric that plugs into the normal plugin.

On Sun, Mar 10, 2013 at 12:09 PM, Nicolas Milliard <niq...@gmail.com> wrote:

Thanks a lot for Gradle Android 0.3 and the documentation.

The Android plugin version 0.3 doesn't offer a "test" task and I was wondering if there is a way to reuse the "test" task from the java plugin instead of writing a complete custom "test" task (and the depending tasks: compileTest, ...) from scratch?

Why: 
The actual android plugin version 0.3 only support instrument-test which require a device to run the test on. 
Some unofficial Android tools like Robolectric allow to do unit testing outside without the need to run on a device or emulator. A classic "test" task would be perfect for this situation.

Best Regards,

Nicolas Milliard

Android lead @ Couchsurfing

--
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 adt-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Ilídio Varandas]

Is there a workaround for the Dex build fail due to the "warning: Ignoring InnerClasses..."?

thanks in advance,

ilídio

Terça-feira, 26 de Fevereiro de 2013 18:03:08 UTC, Xavier Ducrohet escreveu:

[Ilídio Varandas]

Hi Birgitta,

Thanks, it works if I remove the dependency. But I believe that the plugin should not stop with this warning.

Domingo, 28 de Abril de 2013 13:06:59 UTC+1, Birgitta Boeckeler escreveu:

Hi Ilidio,

I could get around it by excluding the transitive dependency that was causing this for me. In my case, it was apache commons' HttpClient.

dependencies {

    compile('my-dependency-that-depended-on-commons-httpclient') {

        exclude module: 'commons-httpclient'

    }

}

httpclient is already included in the Android API, that's why excluding it is fine.

Hope this helps,

Birgitta