gradle developerBuild on master with 1.0-milestone-5 fails

[Ealden Escañan]

Hi,

Running `gradle developerBuild` on master with Gradle 1.0-milestone-5 (and 1.0-milestone-6, which was just released) fails.  I traced this to org.gradle.util.OperatingSystem being changed to org.gradle.os.OperatingSystem and have opened a pull request a few weeks back.  Is there anything I need to change with the PR to get it merged?

https://github.com/jvoegele/gradle-android-plugin/pull/32

Best regards,

--
Ealden Escañan
http://ealden.net

[Ladislav Thon]

https://github.com/jvoegele/gradle-android-plugin/pull/32

Uh oh... Gradle Android Plugin development is kinda stalled, I'd say.

I will pull it if noone objects. Guys, are you comfortable with us requiring Gradle 1.0 milestone 5 and above?

LT

[Ealden Escañan]

Hi Ladislav,

Thanks for this :-).  I think the current master works with M4, which the Gradle developers withdrew due to some major problems.  I stuck with M3 until M6 came out, which seems stable for my day-to-day use (M5 had some problems that affected me).

It may make sense to use a Gradle wrapper to make sure gradle-android-plugin can be built.  I can prepare a PR for it given a specific version...

[Fabio Da Soghe]

Sorry for the very late response, it's a very busy period this one.

Of course I agree for the milestone 5 requisite, I don't see the point to struggle to be backward compatibile in this case.

Fabio

2011/11/19 Ladislav Thon <lad...@gmail.com>

[Marcin Erdmann]

On 11/20/2011 05:45 PM, Ealden Esca�an wrote:
> It may make sense to use a Gradle wrapper to make sure
> gradle-android-plugin can be built. I can prepare a PR for it given a
> specific version...

+1

I've also added Gradle wrapper in my pull request with support for
Discobot (Groovy on Android) project:
https://github.com/jvoegele/gradle-android-plugin/pull/30

Marcin

[Ladislav Thon]

Okay, I decided to go bold and merge some stuff. I didn't do much of testing, but integration tests are OK with Android SDK r13 for me.

First, the Discobot patches are in! I'm terribly sorry for the delay, guys, and thank you VERY MUCH for your effort and patience. I think Marcin should get a commit bit because of this huge contribution!

Next, Ealden's patches for Gradle 1.0 m5 and for IntelliJ IDEA are in. Small and contained, nice to review. Thanks!

I added a Wrapper task and (re)generated the wrapper script for 1.0 m6. I propose that 1.0 m6 is our required version. (I will add a note to README soon.)

I tried to merge Ealden's patches for Android SDK r14, but integration tests were failing for me, both on r14 and r15. Stacktrace is below. I'd LOVE to have SDKs r14+ supported, but this doesn't seem to work for me (yet). It would be GREAT if someone took a look at this -- my personal interest in Android is close to zero nowadays...

Comments? Thoughts? Ideas? Problems?

LT

The promised stacktrace follows:

org.gradle.api.LocationAwareException: Execution failed for task ':androidPackage'.
	at org.gradle.initialization.DefaultExceptionAnalyser.transform(DefaultExceptionAnalyser.java:85)
	at org.gradle.initialization.DefaultGradleLauncher.doBuild(DefaultGradleLauncher.java:114)
	at org.gradle.initialization.DefaultGradleLauncher.run(DefaultGradleLauncher.java:80)
	at org.gradle.initialization.DefaultGradleLauncher$run.call(Unknown Source)
	at com.jvoegele.gradle.android.support.TestProject.runTasks(TestProject.groovy:43)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite$PogoCachedMethodSite.invoke(PogoMetaMethodSite.java:226)
	at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.callCurrent(PogoMetaMethodSite.java:52)
	at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:46)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:133)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:145)
	at com.jvoegele.gradle.android.support.TestProject.runTasks(TestProject.groovy:27)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite$PogoCachedMethodSite.invoke(PogoMetaMethodSite.java:226)
	at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.call(PogoMetaMethodSite.java:64)
	at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:42)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:108)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:124)
	at com.jvoegele.gradle.android.HelloProjectTest.build(HelloProjectTest.groovy:10)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
	at org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
	at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:51)
	at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:63)
	at org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:49)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
	at org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
	at org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
	at org.gradle.messaging.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:75)
	at $Proxy3.processTestClass(Unknown Source)
	at org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:86)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
	at org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
	at org.gradle.messaging.remote.internal.TypeCastDispatch.dispatch(TypeCastDispatch.java:30)
	at org.gradle.messaging.remote.internal.WorkerProtocol.handleIncoming(WorkerProtocol.java:53)
	at org.gradle.messaging.remote.internal.WorkerProtocol.handleIncoming(WorkerProtocol.java:31)
	at org.gradle.messaging.remote.internal.ProtocolStack$ProtocolStage.handleIncoming(ProtocolStack.java:167)
	at org.gradle.messaging.remote.internal.ProtocolStack$BottomStage.handleIncoming(ProtocolStack.java:277)
	at org.gradle.messaging.remote.internal.ProtocolStack$BottomConnection$1.run(ProtocolStack.java:299)
	at org.gradle.messaging.remote.internal.ProtocolStack$ExecuteRunnable.dispatch(ProtocolStack.java:120)
	at org.gradle.messaging.remote.internal.ProtocolStack$ExecuteRunnable.dispatch(ProtocolStack.java:116)
	at org.gradle.messaging.dispatch.AsyncDispatch.dispatchMessages(AsyncDispatch.java:132)
	at org.gradle.messaging.dispatch.AsyncDispatch.access$000(AsyncDispatch.java:33)
	at org.gradle.messaging.dispatch.AsyncDispatch$1.run(AsyncDispatch.java:72)
	at org.gradle.messaging.concurrent.DefaultExecutorFactory$StoppableExecutorImpl$1.run(DefaultExecutorFactory.java:64)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
	at java.lang.Thread.run(Thread.java:662)
Caused by: org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':androidPackage'.
	at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:71)
	at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:48)
	at org.gradle.api.internal.tasks.execution.PostExecutionAnalysisTaskExecuter.execute(PostExecutionAnalysisTaskExecuter.java:34)
	at org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter.execute(SkipUpToDateTaskExecuter.java:55)
	at org.gradle.api.internal.tasks.execution.ValidatingTaskExecuter.execute(ValidatingTaskExecuter.java:57)
	at org.gradle.api.internal.tasks.execution.SkipEmptySourceFilesTaskExecuter.execute(SkipEmptySourceFilesTaskExecuter.java:41)
	at org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:51)
	at org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:52)
	at org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter.execute(ExecuteAtMostOnceTaskExecuter.java:42)
	at org.gradle.api.internal.AbstractTask.executeWithoutThrowingTaskFailure(AbstractTask.java:243)
	at org.gradle.execution.DefaultTaskGraphExecuter.executeTask(DefaultTaskGraphExecuter.java:192)
	at org.gradle.execution.DefaultTaskGraphExecuter.doExecute(DefaultTaskGraphExecuter.java:177)
	at org.gradle.execution.DefaultTaskGraphExecuter.execute(DefaultTaskGraphExecuter.java:83)
	at org.gradle.execution.SelectedTaskExecutionAction.execute(SelectedTaskExecutionAction.java:36)
	at org.gradle.execution.DefaultBuildExecuter.execute(DefaultBuildExecuter.java:70)
	at org.gradle.execution.DefaultBuildExecuter.access$300(DefaultBuildExecuter.java:23)
	at org.gradle.execution.DefaultBuildExecuter$2.proceed(DefaultBuildExecuter.java:80)
	at org.gradle.execution.DryRunBuildExecutionAction.execute(DryRunBuildExecutionAction.java:32)
	at org.gradle.execution.DefaultBuildExecuter.execute(DefaultBuildExecuter.java:70)
	at org.gradle.execution.DefaultBuildExecuter.execute(DefaultBuildExecuter.java:63)
	at org.gradle.initialization.DefaultGradleLauncher.doBuildStages(DefaultGradleLauncher.java:157)
	at org.gradle.initialization.DefaultGradleLauncher.doBuild(DefaultGradleLauncher.java:112)
	... 74 more
Caused by: : com.android.sdklib.build.ApkCreationException: Failed to create '/home/ladicek/work/gradle-android-plugin/build/resources/integrationTest/androidProjects/hello/build/distributions/hello-1.0.apks': No such file or directory
	at com.android.ant.ApkBuilderTask.execute(ApkBuilderTask.java:390)
	at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
	at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
	at groovy.util.AntBuilder.performTask(AntBuilder.java:260)
	at groovy.util.AntBuilder.nodeCompleted(AntBuilder.java:220)
	at org.gradle.api.internal.project.ant.BasicAntBuilder.nodeCompleted(BasicAntBuilder.java:71)
	at groovy.util.BuilderSupport.doInvokeMethod(BuilderSupport.java:147)
	at groovy.util.AntBuilder.doInvokeMethod(AntBuilder.java:170)
	at org.gradle.api.internal.project.ant.BasicAntBuilder.doInvokeMethod(BasicAntBuilder.java:86)
	at groovy.util.BuilderSupport.invokeMethod(BuilderSupport.java:64)
	at org.gradle.api.internal.project.DefaultAntBuilder.super$3$invokeMethod(DefaultAntBuilder.groovy)
	at sun.reflect.GeneratedMethodAccessor12.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:90)
	at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:233)
	at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1054)
	at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnSuperN(ScriptBytecodeAdapter.java:128)
	at org.gradle.api.internal.project.DefaultAntBuilder.invokeMethod(DefaultAntBuilder.groovy:37)
	at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:45)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:120)
	at com.jvoegele.gradle.tasks.android.ApkBuilderTask_r14.execute(ApkBuilderTask_r14.groovy:20)
	at com.jvoegele.gradle.tasks.android.ApkBuilderTask_r14$execute.call(Unknown Source)
	at com.jvoegele.gradle.tasks.android.AndroidPackageTask.createPackage(AndroidPackageTask.groovy:117)
	at com.jvoegele.gradle.tasks.android.AndroidPackageTask.process(AndroidPackageTask.groovy:89)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:90)
	at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:233)
	at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1054)
	at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:884)
	at org.gradle.api.internal.BeanDynamicObject.invokeMethod(BeanDynamicObject.java:158)
	at org.gradle.api.internal.CompositeDynamicObject.invokeMethod(CompositeDynamicObject.java:93)
	at com.jvoegele.gradle.tasks.android.AndroidPackageTask_Decorated.invokeMethod(Unknown Source)
	at groovy.lang.GroovyObject$invokeMethod.call(Unknown Source)
	at org.gradle.util.ReflectionUtil.invoke(ReflectionUtil.groovy:23)
	at org.gradle.api.internal.project.taskfactory.AnnotationProcessingTaskFactory$2.execute(AnnotationProcessingTaskFactory.java:129)
	at org.gradle.api.internal.project.taskfactory.AnnotationProcessingTaskFactory$2.execute(AnnotationProcessingTaskFactory.java:127)
	at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:63)
	... 95 more
Caused by: com.android.sdklib.build.ApkCreationException: Failed to create '/home/ladicek/work/gradle-android-plugin/build/resources/integrationTest/androidProjects/hello/build/distributions/hello-1.0.apks': No such file or directory
	at com.android.sdklib.build.ApkBuilder.checkOutputFile(ApkBuilder.java:865)
	at com.android.sdklib.build.ApkBuilder.init(ApkBuilder.java:429)
	at com.android.sdklib.build.ApkBuilder.<init>(ApkBuilder.java:388)
	at com.android.ant.ApkBuilderTask.execute(ApkBuilderTask.java:333)
	... 138 more

[Ealden Escañan]

Hi Ladislav,

Thanks for the merge :-).  The integration tests are failing with the combination of PR30, as I only branched the R14 changes from master.  I tested that this morning.  I'll rebase the R14 changes based on the current master and make the necessary changes to get R14 to work.

Best regards,

Ealden

[Ladislav Thon]

> The integration tests are failing with the combination of PR30, as I only branched the R14 changes from master.  I tested that this morning.  I'll rebase the R14 changes based on the current master and make the necessary changes to get R14 to work.

Thanks! Will have a look at it when it's ready.

LT

[Fabio Da Soghe]

2011/11/20 Ladislav Thon <lad...@gmail.com>

Okay, I decided to go bold and merge some stuff. I didn't do much of testing, but integration tests are OK with Android SDK r13 for me.

Well done.

 

First, the Discobot patches are in! I'm terribly sorry for the delay, guys, and thank you VERY MUCH for your effort and patience. I think Marcin should get a commit bit because of this huge contribution!

+1 for me

 

Next, Ealden's patches for Gradle 1.0 m5 and for IntelliJ IDEA are in. Small and contained, nice to review. Thanks!

I added a Wrapper task and (re)generated the wrapper script for 1.0 m6. I propose that 1.0 m6 is our required version. (I will add a note to README soon.)

+1 for me

 

I tried to merge Ealden's patches for Android SDK r14, but integration tests were failing for me, both on r14 and r15. Stacktrace is below. I'd LOVE to have SDKs r14+ supported, but this doesn't seem to work for me (yet). It would be GREAT if someone took a look at this -- my personal interest in Android is close to zero nowadays...

I'll watch into this in the next two days: maybe today, for sure not after tomorrow. 

 

Comments? Thoughts? Ideas? Problems?

 

Well, I was seldom partecipating in the last months, so I don't know all the last details. I'll try to recover what I missed.

One question: integration tests are failing for me, complaining about some Android classes not present (sorry I have not the stack trace here and cannot reproduce now). I searched in the readme and the online wiki but I didn't find anything, what am I supposed to supply in order to get a full build working?

Thanks, cheers,

Fabio

[Ladislav Thon]

One question: integration tests are failing for me, complaining about some Android classes not present (sorry I have not the stack trace here and cannot reproduce now). I searched in the readme and the online wiki but I didn't find anything, what am I supposed to supply in order to get a full build working?

It should work right away, when ANDROID_HOME env var is pointing to the right directory. Not sure about Windows, though. I'm afraid that stacktrace is necessary for further investigation. 

LT

[Fabio Da Soghe]

I've set correctly ANDROID_HOME, and I work on linux.

Ok, I'll publish the stack trace as soon as I can.

2011/11/21 Ladislav Thon <lad...@gmail.com>

[Fabio Da Soghe]

Here I am with the stack trace:

20:31:29.086 [ERROR] [org.gradle.BuildExceptionReporter] FAILURE: Build failed with an exception.

20:31:29.086 [ERROR] [org.gradle.BuildExceptionReporter] 

20:31:29.086 [ERROR] [org.gradle.BuildExceptionReporter] * What went wrong:

20:31:29.087 [ERROR] [org.gradle.BuildExceptionReporter] Execution failed for task ':integrationTest'.

20:31:29.088 [ERROR] [org.gradle.BuildExceptionReporter] Cause: There were failing tests. See the report at /home/fabio/devel/git-indigo/gradle-android-plugin/build/reports/tests.

20:31:29.088 [ERROR] [org.gradle.BuildExceptionReporter] 

20:31:29.089 [ERROR] [org.gradle.BuildExceptionReporter] * Exception is:

20:31:29.089 [ERROR] [org.gradle.BuildExceptionReporter] org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':integrationTest'.

20:31:29.089 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:71)

20:31:29.090 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:48)

20:31:29.090 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.api.internal.tasks.execution.PostExecutionAnalysisTaskExecuter.execute(PostExecutionAnalysisTaskExecuter.java:34)

20:31:29.090 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter.execute(SkipUpToDateTaskExecuter.java:55)

20:31:29.090 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.api.internal.tasks.execution.ValidatingTaskExecuter.execute(ValidatingTaskExecuter.java:57)

20:31:29.091 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.api.internal.tasks.execution.SkipEmptySourceFilesTaskExecuter.execute(SkipEmptySourceFilesTaskExecuter.java:41)

20:31:29.091 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:51)

20:31:29.091 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:52)

20:31:29.091 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter.execute(ExecuteAtMostOnceTaskExecuter.java:42)

20:31:29.092 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.api.internal.AbstractTask.executeWithoutThrowingTaskFailure(AbstractTask.java:243)

20:31:29.092 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.execution.DefaultTaskGraphExecuter.executeTask(DefaultTaskGraphExecuter.java:192)

20:31:29.092 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.execution.DefaultTaskGraphExecuter.doExecute(DefaultTaskGraphExecuter.java:177)

20:31:29.092 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.execution.DefaultTaskGraphExecuter.execute(DefaultTaskGraphExecuter.java:83)

20:31:29.093 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.execution.SelectedTaskExecutionAction.execute(SelectedTaskExecutionAction.java:36)

20:31:29.093 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.execution.DefaultBuildExecuter.execute(DefaultBuildExecuter.java:70)

20:31:29.093 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.execution.DefaultBuildExecuter.access$300(DefaultBuildExecuter.java:23)

20:31:29.093 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.execution.DefaultBuildExecuter$2.proceed(DefaultBuildExecuter.java:80)

20:31:29.093 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.execution.DryRunBuildExecutionAction.execute(DryRunBuildExecutionAction.java:32)

20:31:29.094 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.execution.DefaultBuildExecuter.execute(DefaultBuildExecuter.java:70)

20:31:29.094 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.execution.DefaultBuildExecuter.execute(DefaultBuildExecuter.java:63)

20:31:29.094 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.initialization.DefaultGradleLauncher.doBuildStages(DefaultGradleLauncher.java:157)

20:31:29.094 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.initialization.DefaultGradleLauncher.doBuild(DefaultGradleLauncher.java:112)

20:31:29.095 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.initialization.DefaultGradleLauncher.run(DefaultGradleLauncher.java:80)

20:31:29.095 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.launcher.cli.RunBuildAction.execute(RunBuildAction.java:42)

20:31:29.095 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.launcher.cli.RunBuildAction.execute(RunBuildAction.java:28)

20:31:29.095 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.launcher.exec.ExceptionReportingAction.execute(ExceptionReportingAction.java:32)

20:31:29.096 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.launcher.exec.ExceptionReportingAction.execute(ExceptionReportingAction.java:21)

20:31:29.096 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.launcher.cli.CommandLineActionFactory$WithLoggingAction.execute(CommandLineActionFactory.java:233)

20:31:29.108 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.launcher.cli.CommandLineActionFactory$WithLoggingAction.execute(CommandLineActionFactory.java:217)

20:31:29.109 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.launcher.Main.doAction(Main.java:48)

20:31:29.109 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.launcher.exec.EntryPoint$1.execute(EntryPoint.java:53)

20:31:29.109 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.launcher.exec.EntryPoint$1.execute(EntryPoint.java:51)

20:31:29.109 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.launcher.exec.Execution.execute(Execution.java:28)

20:31:29.110 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.launcher.exec.EntryPoint.run(EntryPoint.java:39)

20:31:29.110 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.launcher.Main.main(Main.java:39)

20:31:29.110 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.launcher.ProcessBootstrap.runNoExit(ProcessBootstrap.java:51)

20:31:29.110 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.launcher.ProcessBootstrap.run(ProcessBootstrap.java:33)

20:31:29.110 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.launcher.GradleMain.main(GradleMain.java:24)

20:31:29.111 [ERROR] [org.gradle.BuildExceptionReporter] Caused by: org.gradle.api.GradleException: There were failing tests. See the report at /home/fabio/devel/git-indigo/gradle-android-plugin/build/reports/tests.

20:31:29.111 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.api.tasks.testing.Test.executeTests(Test.java:372)

20:31:29.111 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.api.internal.BeanDynamicObject.invokeMethod(BeanDynamicObject.java:158)

20:31:29.111 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.api.internal.CompositeDynamicObject.invokeMethod(CompositeDynamicObject.java:93)

20:31:29.112 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.api.tasks.testing.Test_Decorated.invokeMethod(Unknown Source)

20:31:29.112 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.util.ReflectionUtil.invoke(ReflectionUtil.groovy:23)

20:31:29.112 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.api.internal.project.taskfactory.AnnotationProcessingTaskFactory$2.execute(AnnotationProcessingTaskFactory.java:129)

20:31:29.112 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.api.internal.project.taskfactory.AnnotationProcessingTaskFactory$2.execute(AnnotationProcessingTaskFactory.java:127)

20:31:29.112 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:63)

20:31:29.113 [ERROR] [org.gradle.BuildExceptionReporter] ... 37 more

ANDROID_HOME is pointing to the root Android SDK install dir, that is the dir where I extracted the sdk tar. 

In the Eclipse project there are some missing classes: it wants classes from the Android classpath, but there is not any Android jar in the build path...

2011/11/21 Fabio Da Soghe <fabiod...@gmail.com>

[Ladislav Thon]

20:31:29.088 [ERROR] [org.gradle.BuildExceptionReporter] Cause: There were failing tests. See the report at /home/fabio/devel/git-indigo/gradle-android-plugin/build/reports/tests.

Ah, failing tests... What version of Android SDK do you have installed? The tests will fail with SDK r14 and higher, and if you are updating your Android SDK regularly, you will most certainly have r15 installed now.

If you have SDK r13 or less, attach the results from /home/fabio/devel/git-indigo/gradle-android-plugin/build/reports/tests.

LT

[Marcin Erdmann]

On 11/20/2011 11:57 PM, Ladislav Thon wrote:
> Okay, I decided to go bold and merge some stuff. I didn't do much of
> testing, but integration tests are OK with Android SDK r13 for me.
>
> First, the Discobot patches are in! I'm terribly sorry for the delay,
> guys, and thank you VERY MUCH for your effort and patience. I think
> Marcin should get a commit bit because of this huge contribution!

Thank you very much. Especially as you've said that you don't have much
interest in Android at the moment. The project and you will probably get
mentioned during our talk on Groovy & Grails Exchange in London next
month about our efforts on getting Groovy running on Android.

To be honest I think that giving me commit rights would be a step to
far. I also have little interest in Android and I don't think I would
ever use the rights. It's a little bit selfish but we actually only
needed the fixes so that we are able now to build conceptual Groovy apps
for Android. I only added a bit more than what was necessary for us to
at least give something back to the project;).

Thanks again,
Marcin

[Ladislav Thon]

Thank you very much. Especially as you've said that you don't have much interest in Android at the moment. The project and you will probably get mentioned during our talk on Groovy & Grails Exchange in London next month about our efforts on getting Groovy running on Android.

Cool! Always there to help spreading Groovy superiority amongst the ordinary Java people! :-)

 

To be honest I think that giving me commit rights would be a step to far. I also have little interest in Android and I don't think I would ever use the rights.

Might be right, but it wouldn't do any harm. And if we ever made a mistake that cause some trouble for you, you could fix that right away. Because, as you see, Gradle Android Plugin is going through some kind of winter lethargy right now :-)

LT

[Fabio Da Soghe]

Yes, I'm on r15 now.

If it's only a matter of tests, I can live with it, by now.

I'm trying with the pull request from Ealden, it breaks here:

Caused by: : Android Target is not set.

21:58:43.499 [ERROR] [org.gradle.BuildExceptionReporter] at com.android.ant.NewSetupTask.execute(NewSetupTask.java:224)

21:58:43.499 [ERROR] [org.gradle.BuildExceptionReporter] at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)

21:58:43.499 [ERROR] [org.gradle.BuildExceptionReporter] at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)

21:58:43.500 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.api.internal.project.ant.BasicAntBuilder.nodeCompleted(BasicAntBuilder.java:71)

21:58:43.500 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.api.internal.project.ant.BasicAntBuilder.doInvokeMethod(BasicAntBuilder.java:86)

21:58:43.500 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.api.internal.project.DefaultAntBuilder.super$3$invokeMethod(DefaultAntBuilder.groovy)

21:58:43.500 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.api.internal.project.DefaultAntBuilder.invokeMethod(DefaultAntBuilder.groovy:37)

21:58:43.500 [ERROR] [org.gradle.BuildExceptionReporter] at com.jvoegele.gradle.plugins.android.AndroidPlugin.androidSetup(AndroidPlugin.groovy:118)

21:58:43.501 [ERROR] [org.gradle.BuildExceptionReporter] at com.jvoegele.gradle.plugins.android.AndroidPlugin.apply(AndroidPlugin.groovy:62)

I'm investigating: from the Ant source task, it needs a "target" parameter that we seem to not supply, from our AndroidPlugin class (line 118 of Ealden's branch).

Now, I'm guessing what that parameter stands for...

2011/11/21 Ladislav Thon <lad...@gmail.com>

[Fabio Da Soghe]

Maybe I got it: it needs the value from the project.properties on the root of the project.

If I'm not wrong, that same file is created from the ADT? What a trip these values do... :-/  

2011/11/21 Fabio Da Soghe <fabiod...@gmail.com>

Yes, I'm on r15 now.

[Ladislav Thon]

Yes, I'm on r15 now.

If it's only a matter of tests, I can live with it, by now.

It's a matter of us not supporting r14+ (yet). This of course manifestates as failing tests.

LT

[Ealden Escañan]

Hi.

I've rebased the android-r14-support branch based on the latest master and added commit e2587079 to get it to pass again with developerBuild.

This works with R14 but will now fail on R13 as AndroidPlugin.androidSetup() is now specific to R14.  I was thinking of extracting the contents of androidSetup() to an AndroidSetup class, so we can provide an _r14 specific one on top of what we had before.  Is this a good idea?

[Fabio Da Soghe]

2011/11/21 Ealden Escañan <eal...@gmail.com>

Hi Ladislav,

Thanks for the merge :-).  The integration tests are failing with the combination of PR30, as I only branched the R14 changes from master.  I tested that this morning.  I'll rebase the R14 changes based on the current master and make the necessary changes to get R14 to work.

Best regards,

Ealden

Now, I confess I'm getting a bit lost among all the pull requests, branches and sdks... I tried to merge your pull request (PR #34) on current master but it results impossible: Eclipse (EGit) complaints about more then one base for the merge, maybe it's the rebase matter you're talking about (I'm not a Git expert, never used rebasing).

BUT. I managed to get a build (a real world Android project, not a simple one) working, on Android SDK r15 (integration tests still failing, sorry Ladislav).

I checked out your branch (android-r14-support) and made this little modification:

diff --git a/src/main/groovy/com/jvoegele/gradle/plugins/android/AndroidPlugin.groovy b/src/main/groovy/com/jvoegele/gradle/plugins/android/AndroidPlugin.groovy

index bbd2a47..b88ed2a 100644

--- a/src/main/groovy/com/jvoegele/gradle/plugins/android/AndroidPlugin.groovy

+++ b/src/main/groovy/com/jvoegele/gradle/plugins/android/AndroidPlugin.groovy

@@ -33,7 +33,7 @@

   

   private static final ANDROID_GROUP = "Android";

   

-  private static final PROPERTIES_FILES = ['local', 'build', 'default']

+  private static final PROPERTIES_FILES = ['local', 'build', 'default', 'project']

   private static final ANDROID_JARS = ['anttasks', 'sdklib', 'androidprefs', 'apkbuilder', 'jarutils']

 

   private AndroidPluginConvention androidConvention

Is this patch needed for r14 too, or there is another incompat between r14 and r15?

Cheers,

Fabio

[Fabio Da Soghe]

Hi.

It seems a good idea to me because it goes aligned with the other support classes already created over time. Then choose what class to use based on the sdk revision, as already done with the other classes.

I'm working on your rebased branch... and I cannot build anymore, with my patch I've just posted here. Have you tried the patch? Just to know if it introduces another regression with oldest sdks...

Anyway: the new branch doesn't work for me because it doesn't zipalign the final apk. I'm investigating why...

2011/11/21 Ealden Escañan <eal...@gmail.com>

[Fabio Da Soghe]

Done the merging from your pull request. My problem is still there: it doesn't produce the zipaligned apk.

It's weird because your previous branch (before the rebasing) worked well... there is some difference in the packaging process?

2011/11/21 Fabio Da Soghe <fabiod...@gmail.com>

Hi.

[Ladislav Thon]

This works with R14 but will now fail on R13 as AndroidPlugin.androidSetup() is now specific to R14.  I was thinking of extracting the contents of androidSetup() to an AndroidSetup class, so we can provide an _r14 specific one on top of what we had before.  Is this a good idea?

Yes. As you've noted, this approach is already used and I personally find it simple and satisfying.

LT

[Ealden Escañan]

Hi Fabio,

On Tue, Nov 22, 2011 at 6:56 AM, Fabio Da Soghe <fabiod...@gmail.com> wrote:

Done the merging from your pull request. My problem is still there: it doesn't produce the zipaligned apk.

It's weird because your previous branch (before the rebasing) worked well... there is some difference in the packaging process?

I actually haven't used the sign and align, so I wasn't able to test it.  In any case, I did a rebase in order to branch from the current master, which includes my 1.0-milestone-5 fixes as well as the Discobot patches.  I believe there has been some changes with regards to sign and align in the Discobot patches, but I haven't takes an extensive look on those.

Could you take a look against the current master as well?  If that works then the R14-specific classes might need some changes to make it work.

Also, I started porting Spring's Android Samples project (spring-android-showcase) to Gradle so I have a not-so-simple Android project to test on.  I'm hoping to duplicate the problems that you are seeing.  I have a branch that works with the current 1.0.0 gradle-android-plugin:

https://github.com/ealden/spring-android-samples/tree/gradle

I had to comment out androidSignAndAlign however as Gradle is returning the error below.  I have 1.0-milestone-6 and R13 currently.  Any ideas if I configured it wrong?  The values I used are from http://developer.android.com/guide/publishing/app-signing.html

Cause: Could not find method androidSignAndAlign() for arguments [build_4r0592k3l1i38ghjuigmfulrnn$_run_closure5@6e4d4d5e] on root project 'client'.

Here is a gist for the stacktrace and DEBUG logs:

https://gist.github.com/1384775

 

Best regards,

[Ealden Escañan]

Hi Fabio,

On Tue, Nov 22, 2011 at 11:03 AM, Ealden Escañan <eal...@gmail.com> wrote:

Also, I started porting Spring's Android Samples project (spring-android-showcase) to Gradle so I have a not-so-simple Android project to test on.  I'm hoping to duplicate the problems that you are seeing.  I have a branch that works with the current 1.0.0 gradle-android-plugin:

https://github.com/ealden/spring-android-samples/tree/gradle

I had to comment out androidSignAndAlign however as Gradle is returning the error below.  I have 1.0-milestone-6 and R13 currently.  Any ideas if I configured it wrong?  The values I used are from http://developer.android.com/guide/publishing/app-signing.html

Cause: Could not find method androidSignAndAlign() for arguments [build_4r0592k3l1i38ghjuigmfulrnn$_run_closure5@6e4d4d5e] on root project 'client'.

Never mind on this.  I guess this was caused by an incompatibility with gradle-android-plugin 1.0.0 and Gradle 1.0-milestone-6, as using 1.1.0-SNAPSHOT worked.  Here is my spring-android-showcase branch using 1.1.0-SNAPSHOT + android-r14-support branch (I've deployed a copy at http://maven.teamcodeflux.com/external):

https://github.com/ealden/spring-android-samples/tree/android-r14-support

[Fabio Da Soghe]

I'll work on this today evening (now it's morning here).

Thanks,

Fabio

2011/11/22 Ealden Escañan <eal...@gmail.com>

[Marcin Erdmann]

On 11/21/2011 09:47 PM, Ladislav Thon wrote:
> To be honest I think that giving me commit rights would be a step to
> far. I also have little interest in Android and I don't think I
> would ever use the rights.
>
>
> Might be right, but it wouldn't do any harm. And if we ever made a
> mistake that cause some trouble for you, you could fix that right away.
> Because, as you see, Gradle Android Plugin is going through some kind of
> winter lethargy right now :-)

That's actually the only scenario where the commit rights could prove
quite useful so maybe indeed it's not such a bad idea!

Marcin

[Ealden Escañan]

Hi

On Tue, Nov 22, 2011 at 7:45 AM, Ladislav Thon <lad...@gmail.com> wrote:

This works with R14 but will now fail on R13 as AndroidPlugin.androidSetup() is now specific to R14.  I was thinking of extracting the contents of androidSetup() to an AndroidSetup class, so we can provide an _r14 specific one on top of what we had before.  Is this a good idea?

Yes. As you've noted, this approach is already used and I personally find it simple and satisfying.

I've opened a pull request for this: https://github.com/jvoegele/gradle-android-plugin/pull/35

Best regards,

[Ladislav Thon]

I've opened a pull request for this: https://github.com/jvoegele/gradle-android-plugin/pull/35

I'll try to have a look at it this evening.

Oh, now I see that your first pull request was already merged (by Fabio I guess?), that's great!

LT

[Ladislav Thon]

And now I see that Danail Nachev worked on supporting Android SDK r15 too, see https://github.com/dnachev/gradle-android-plugin/commits/android_r15_support. I think he has a little mistake in there, he shouldn't be checking for sdkVersion < 15 but sdkVersion < 14, but other than that, it might contain some useful ideas. Hopefully, he will speak to us -- but it looks like we will have proper ICS SDK support soon anyway.

LT

[Fabio Da Soghe]

2011/11/23 Ladislav Thon <lad...@gmail.com>

I've opened a pull request for this: https://github.com/jvoegele/gradle-android-plugin/pull/35

I'll try to have a look at it this evening.

Good. As I wrote, I cannot work on it before friday.

 

Oh, now I see that your first pull request was already merged (by Fabio I guess?), that's great!

Yes, merged (on master) and pushed.

As I said, I cannot get my build working; it seems because I'm using a deprecated way to sign and align the apk (indeed my problem is that I'm not getting any apk at all). There is a new task, signAndAlignApk or something like that, to be used.

I missed this one, I don't remember when it was deprecated... probably my fault: I wasn't able to properly follow this project in the past months.

Can someone confirm that the old signing method is not working anymore (and the new one is expected to work)?

Thanks :o)

Fabio

[Ladislav Thon]

Can someone confirm that the old signing method is not working anymore (and the new one is expected to work)?

It should be working, you should still be able to specify signing configuration in androidPackage {...} closure. If not, it's a bug and must be fixed.

LT

[Ealden Escañan]

Hi,

On Wed, Nov 23, 2011 at 5:31 PM, Ladislav Thon <lad...@gmail.com> wrote:

Can someone confirm that the old signing method is not working anymore (and the new one is expected to work)?

It should be working, you should still be able to specify signing configuration in androidPackage {...} closure. If not, it's a bug and must be fixed.

I'm assuming that the "old" method is to use androidPackage {} instead of the current androidSignAndAlign {}, as I dug up from the history in README.md:

https://github.com/jvoegele/gradle-android-plugin/blob/f4c2d7e66a56bdbce555055619cdf7399adbca2f/README.md

Either androidPackage and androidSignAndAlign works with my test build.gradle, with R13, R14, or R15:

https://github.com/ealden/spring-android-samples/blob/android-r14-support/spring-android-showcase/client/build.gradle

I'm interested to know if there are any differences with the configuration, but I pretty much copied the sample in README and used that.  Stacktrace / copy of test failures would be helpful too.

[Ladislav Thon]

I'm assuming that the "old" method is to use androidPackage {} instead of the current androidSignAndAlign {}, as I dug up from the history in README.md:

Yes.

 

Either androidPackage and androidSignAndAlign works with my test build.gradle, with R13, R14, or R15:

https://github.com/ealden/spring-android-samples/blob/android-r14-support/spring-android-showcase/client/build.gradle

I would think so, but still good to know.

Btw, Gradle buildscript for Spring Android samples is a great real-world-style example, thanks!

LT

[Fabio Da Soghe]

2011/11/23 Ealden Escañan <eal...@gmail.com>

Hi,

On Wed, Nov 23, 2011 at 5:31 PM, Ladislav Thon <lad...@gmail.com> wrote:

Can someone confirm that the old signing method is not working anymore (and the new one is expected to work)?

It should be working, you should still be able to specify signing configuration in androidPackage {...} closure. If not, it's a bug and must be fixed.

I'm assuming that the "old" method is to use androidPackage {} instead of the current androidSignAndAlign {}, as I dug up from the history in README.md:

https://github.com/jvoegele/gradle-android-plugin/blob/f4c2d7e66a56bdbce555055619cdf7399adbca2f/README.md

Yes, correct.

 

Either androidPackage and androidSignAndAlign works with my test build.gradle, with R13, R14, or R15:

https://github.com/ealden/spring-android-samples/blob/android-r14-support/spring-android-showcase/client/build.gradle

Ok. So it seems it's an exclusive problem of my project. I'll investigate and let you know.

 

I'm interested to know if there are any differences with the configuration, but I pretty much copied the sample in README and used that.  Stacktrace / copy of test failures would be helpful too.

I'll provide as soon as I can, that means friday for me (sorry but Android development is not my primary job... yet).

[Ladislav Thon]

I've opened a pull request for this: https://github.com/jvoegele/gradle-android-plugin/pull/35

I'll try to have a look at it this evening.

OK. Integration tests are passing for me both on Android SDK r15 and r13 (actually, not exactly r13, it's r15 with tools/ directory from r13 but platform-tools/ still from r15 -- fuck, I should have backed up my SDK r13 directory before upgrading... but still) and my simple app builds and installs to a device just fine.

So -- I pushed this. Ealden, thanks for your contribution! I propose you get a commit bit too, in addition to Marcin.

Now, let's get Fabio's problems solved and then do new release (1.1.0 or 1.0.1?) with support for Ice Cream Sandwich SDK. It's badly needed, I guess.

LT

[Ealden Escañan]

Hi,

On Thu, Nov 24, 2011 at 6:02 AM, Ladislav Thon <lad...@gmail.com> wrote:

OK. Integration tests are passing for me both on Android SDK r15 and r13 (actually, not exactly r13, it's r15 with tools/ directory from r13 but platform-tools/ still from r15 -- fuck, I should have backed up my SDK r13 directory before upgrading... but still) and my simple app builds and installs to a device just fine.

Heh, the older SDKs are still available if you enter their URLS directly.  I ended up getting all of them, making sure I didn't upgrade the SDK tools, and switching between them through symlinks.  A bit tedious but I guess that's part of dealing with Android development.

 

So -- I pushed this. Ealden, thanks for your contribution! I propose you get a commit bit too, in addition to Marcin.

Now, let's get Fabio's problems solved and then do new release (1.1.0 or 1.0.1?) with support for Ice Cream Sandwich SDK. It's badly needed, I guess.

Thanks for the merge.  We're using gradle-android-plugin for all our Android projects here at work so we're interested in getting this to work with ICS :-).

[Ladislav Thon]

Heh, the older SDKs are still available if you enter their URLS directly.  I ended up getting all of them, making sure I didn't upgrade the SDK tools, and switching between them through symlinks.  A bit tedious but I guess that's part of dealing with Android development.

Are they? I managed to download older SDK tools archives, but whole SDKs (meaning the whole android-sdk-linux_x86 directory with tools, platform-tools, docs etc.)? I'll try to investigate some more, because I'd love to have some older SDKs installed...

 

 We're using gradle-android-plugin for all our Android projects here at work

Wow, great to know! That's super-awesome! :-)

LT

[Fabio Da Soghe]

2011/11/23 Ladislav Thon <lad...@gmail.com>

I've opened a pull request for this: https://github.com/jvoegele/gradle-android-plugin/pull/35

I'll try to have a look at it this evening.

OK. Integration tests are passing for me both on Android SDK r15 and r13 (actually, not exactly r13, it's r15 with tools/ directory from r13 but platform-tools/ still from r15 -- fuck, I should have backed up my SDK r13 directory before upgrading... but still) and my simple app builds and installs to a device just fine.

Very happy to hear that.

 

So -- I pushed this. Ealden, thanks for your contribution! I propose you get a commit bit too, in addition to Marcin.

+1 for me. About this... who can give the commit bit? Only Jason?

 

Now, let's get Fabio's problems solved and then do new release (1.1.0 or 1.0.1?) with support for Ice Cream Sandwich SDK. It's badly needed, I guess.

I vote for 1.1.0. There were many improvements in the last pull requests.

As I said, I'll work to fix my project tomorrow. Of course I'll post here as soon as I have news.

Cheers,

Fabio

[Ladislav Thon]

So -- I pushed this. Ealden, thanks for your contribution! I propose you get a commit bit too, in addition to Marcin.

+1 for me. About this... who can give the commit bit? Only Jason?

I think so.

 

Now, let's get Fabio's problems solved and then do new release (1.1.0 or 1.0.1?) with support for Ice Cream Sandwich SDK. It's badly needed, I guess.

I vote for 1.1.0. There were many improvements in the last pull requests.

+1

 

As I said, I'll work to fix my project tomorrow. Of course I'll post here as soon as I have news.

Don't hesitate to post stack-traces or gradle --debug output if you need some help :-)

LT

[Ealden Escañan]

Hi,

On Thu, Nov 24, 2011 at 5:00 PM, Ladislav Thon <lad...@gmail.com> wrote:

Are they? I managed to download older SDK tools archives, but whole SDKs (meaning the whole android-sdk-linux_x86 directory with tools, platform-tools, docs etc.)? I'll try to investigate some more, because I'd love to have some older SDKs installed...

 

Yes.  Just replace the release number from the download link, like so:

http://dl.google.com/android/android-sdk_r15-linux.tgz

http://dl.google.com/android/android-sdk_r14-linux.tgz

http://dl.google.com/android/android-sdk_r13-linux_x86.tgz

http://dl.google.com/android/android-sdk_r12-linux_x86.tgz

Releases older than R14 seems to have that _x86 bit, but later ones don't.  I then create a "platforms" directory and symlink it from each of the release.  Apparently older releases couldn't download SDKs, so I rely on the latest release to download, and share them to the older releases via the symlink.

Just make sure not to upgrade the SDK from the older releases :-).

[Ladislav Thon]

Yes.  Just replace the release number from the download link, like so:

http://dl.google.com/android/android-sdk_r15-linux.tgz

http://dl.google.com/android/android-sdk_r14-linux.tgz

http://dl.google.com/android/android-sdk_r13-linux_x86.tgz

http://dl.google.com/android/android-sdk_r12-linux_x86.tgz

Releases older than R14 seems to have that _x86 bit, but later ones don't.  I then create a "platforms" directory and symlink it from each of the release.  Apparently older releases couldn't download SDKs, so I rely on the latest release to download, and share them to the older releases via the symlink.

Just make sure not to upgrade the SDK from the older releases :-)

Thanks for the info!

LT

[Fabio Da Soghe]

2011/11/24 Ladislav Thon <lad...@gmail.com>

Yes, it can be a very useful tricks! If I had known before, I'ld have saved a lot of problems!

[Fabio Da Soghe]

After a bit more digging, I'm realizing that the original task,
AndroidPackage, don't sign anymore. That is: it creates the unsigned
apk, than stops.

The original task took care of signing and zipaligning.

This is the reason of my actual build failure. You said it was working
for you, maybe you have a build.gradle that doesn't request to have a
final signed apk? Otherwise I cannot understand how it can work...

Anyway, I'm doing the migration to the new task.

Fabio

> https://github.com/ealden/spring-android-samples/tree/android-r14-sup...
>
> --
> Ealden Escañanhttp://ealden.net

[Ladislav Thon]

After a bit more digging, I'm realizing that the original task,
AndroidPackage, don't sign anymore. That is: it creates the unsigned
apk, than stops.

The original task took care of signing and zipaligning.

Uh oh, yes. You are actually depending on this AndroidPackage task? I considered this internal, which is why I merged Marcin's changes which took the signing and zipaligning out from AndroidPackage to a separate task, while still allowing the signing configuration inside the androidPackage closure (so that people don't have to change their buildscripts). When I was saying that "it should still work", I was thinking about the configuration, not the actual semantics of AndroidPackage task.

Can you share some details of your configuration? I can imagine that you have some custom task that depends on androidPackage and expects signed and zipaligned apk... yes, this won't work now. I didn't think about this situation before, I thought that people would depend on 'assemble' or 'build' or some of these...

Hmm... don't know what to do about that now...

LT

[Fabio Da Soghe]

2011/11/25 Ladislav Thon <lad...@gmail.com>

Now I understand the whole picture :-)

Yes, as you thought, I do depend on androidPackage building the actual apk. I do this because I want to calculate the crc for the dex file into the apk, then put the crc into a property file then rebuild the apk with the final property crc-ed file.

My task is this:

task crcPatch {

doLast {

project.classesDexAntiTamperingCrc32Value = calcCrc32ClassesDex()

copy {

expand (project.properties)

from (sourceSets.androidOvr.resources) {

include '**/strings_no_local.xml'  // This is my file with the crc code

}

into (sourceSets.androidOvr.classesDir)

}

delete(apkArchivePath)

}

dependsOn {

androidPackage

}

}

Then, to recreate the final (for real, this time!) apk, I created this task:

task(androidRepackage, type: com.jvoegele.gradle.tasks.android.AndroidPackageTask) {

dependsOn crcPatch

keyStore = XXX

keyAlias = XXX

keyStorePassword = XXX

keyAliasPassword = XXX

}

assemble {

dependsOn androidRepackage

}

Of course, now it's broken. I think I have to duplicate the two tasks now, creating androidRepackage and androidResignAndRealign, and setting dependencies accordingly. It's not a problem... if it works.

So we have a partial breaking change... for this, I think it would be appropriate to release a 1.1.0 version. What do you think about it?

Fabio

[Fabio Da Soghe]

2011/11/25 Ladislav Thon <lad...@gmail.com>

I didn't think about this situation before, I thought that people would depend on 'assemble' or 'build' or some of these...

I thought about this but I cannot figure out how to accomplish what I need in another way... dipending directly on 'assemble' seemed to me a too big work: I mean, how many other things depend on that task, what I have to configure in order to have it doing only what I need (that is, creating the apk)?

[Ladislav Thon]

Yes, as you thought, I do depend on androidPackage building the actual apk. I do this because I want to calculate the crc for the dex file into the apk, then put the crc into a property file then rebuild the apk with the final property crc-ed file.

Now thinking about it, such thing can be more common than I thought... I will meditate about this over the weekend, I can't see an easy solution right now.

 

Of course, now it's broken. I think I have to duplicate the two tasks now, creating androidRepackage and androidResignAndRealign, and setting dependencies accordingly. It's not a problem... if it works.

Yeah, this should work. But it's clumsy, at least.

 

So we have a partial breaking change... for this, I think it would be appropriate to release a 1.1.0 version. What do you think about it?

Let's think about it some more, maybe we can come up with nicer solution that would work for Marcin too. I would hate to do so, but reverting breaking changes is always a possibility.

LT

[Fabio Da Soghe]

Anyway, I've done my corrections, now it works like a charm.

So, the plugin is good to go, for me.

Er... who can do the release? I don't remember well how things were working about the release process... :-/

2011/11/25 Fabio Da Soghe <fabiod...@gmail.com>

[Fabio Da Soghe]

2011/11/25 Ladislav Thon <lad...@gmail.com>

Let's think about it some more, maybe we can come up with nicer solution that would work for Marcin too. I would hate to do so, but reverting breaking changes is always a possibility.

LT

Ok. I'll work on my project in the next days, I'll think about it.

Cheers,

Fabio

[Fabio Da Soghe]

I think I've found another problem.

In my Android project I have a "normal" resource file, that is a .properties file in /src/main/resources.

I discovered that Gradle m6 is putting by default resources in /build/resources/main, not in /build/classes/main as it was doing before.

In ApkBuilderTask_* classes (at least in r8 and r14, I've checked them) we pass this parameter to the apkbuilder Ant task:

      // Takes resource files from the source folder - classes are processed by the dx command

      sourcefolder(path: project.sourceSets.main.output.classesDir)

So, it's missing the project.sourceSets.main.output.resourcesDir

Does anyone know how to add more then one directory to the apkbuilder Ant task?

Cheers,

Fabio

2011/11/25 Fabio Da Soghe <fabiod...@gmail.com>

2011/11/25 Ladislav Thon <lad...@gmail.com>

[Fabio Da Soghe]

I've done this (bold the new line):

    ant.apkbuilder(outfolder: project.libsDir,

                   resourcefile: ant['resource.package.file.name'],

                   apkfilepath: androidConvention.unsignedArchivePath,

                   debugsigning: args.get('sign', false),

                   hascode: ant['manifest.hasCode'],

                   verbose: args.get('verbose', false)) {

      dex(path: androidConvention.intermediateDexFile)

      // Takes resource files from the source folder - classes are processed by the dx command

      sourcefolder(path: project.sourceSets.main.output.classesDir)

      sourcefolder(path: project.sourceSets.main.output.resourcesDir)

      nativefolder(path: androidConvention.nativeLibsDir)

    }

It works for me. I'ld apply this to r14, r8 and r7 (not r6 because there is not sourcefolder parameter) then I'll push to let you do a little test and review, if and when you can.

Bye bye,

[Jason Voegele]

On Nov 25, 2011, at 5:58 AM, Fabio Da Soghe wrote:
> Anyway, I've done my corrections, now it works like a charm.
>
> So, the plugin is good to go, for me.
>
> Er... who can do the release? I don't remember well how things were working about the release process... :-/

Hi guys, sorry I haven't been following this thread too very closely but I do know that I need to step in and take care of a couple of things. I'll try to get to that tomorrow. Thanks for your patience. :-)

--
Jason Voegele
"Cogito ergo I'm right and you're wrong."
-- Blair Houghton

[Ladislav Thon]

> In my Android project I have a "normal" resource file, that is a .properties file in /src/main/resources.

We should put this situation in our test suite. But I won't get to programming for next two days, I think.

LT