Splunk AppDynamics

Build fails with appdynamics-gradle-plugin 24.1.0

Jerg_Weick
Explorer

Using the new 

appdynamics-gradle-plugin 24.1.0

makes the build fail with the following exception:

Execution failed for task ':ControlCenterApp:expandReleaseArtProfileWildcards'.
> A failure occurred while executing com.android.build.gradle.internal.tasks.ExpandArtProfileWildcardsTask$ExpandArtProfileWildcardsWorkAction
> invalid END header (bad central directory offset)

The relevant stacktrace part:

...
Caused by: java.util.zip.ZipException: invalid END header (bad central directory offset)
at com.android.tools.profgen.ArchiveClassFileResourceProvider.getClassFileResources(ClassFileResource.kt:62)
at com.android.tools.profgen.ProfgenUtilsKt.expandWildcards(ProfgenUtils.kt:60)
at com.android.build.gradle.internal.tasks.ExpandArtProfileWildcardsTask$ExpandArtProfileWildcardsWorkAction.run(ExpandArtProfileWildcardsTask.kt:120)
at com.android.build.gradle.internal.profile.ProfileAwareWorkAction.execute(ProfileAwareWorkAction.kt:74)
at org.gradle.workers.internal.DefaultWorkerServer.execute(DefaultWorkerServer.java:63)
at org.gradle.workers.internal.NoIsolationWorkerFactory$1$1.create(NoIsolationWorkerFactory.java:66)
at org.gradle.workers.internal.NoIsolationWorkerFactory$1$1.create(NoIsolationWorkerFactory.java:62)
at org.gradle.internal.classloader.ClassLoaderUtils.executeInClassloader(ClassLoaderUtils.java:100)
at org.gradle.workers.internal.NoIsolationWorkerFactory$1.lambda$execute$0(NoIsolationWorkerFactory.java:62)
at org.gradle.workers.internal.AbstractWorker$1.call(AbstractWorker.java:44)
at org.gradle.workers.internal.AbstractWorker$1.call(AbstractWorker.java:41)
at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:204)
at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:199)
at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute(DefaultBuildOperationRunner.java:66)
at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute(DefaultBuildOperationRunner.java:59)
at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:157)
at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:59)
at org.gradle.internal.operations.DefaultBuildOperationRunner.call(DefaultBuildOperationRunner.java:53)
at org.gradle.internal.operations.DefaultBuildOperationExecutor.call(DefaultBuildOperationExecutor.java:73)
at org.gradle.workers.internal.AbstractWorker.executeWrappedInBuildOperation(AbstractWorker.java:41)
at org.gradle.workers.internal.NoIsolationWorkerFactory$1.execute(NoIsolationWorkerFactory.java:59)
at org.gradle.workers.internal.DefaultWorkerExecutor.lambda$submitWork$0(DefaultWorkerExecutor.java:170)
at org.gradle.internal.work.DefaultConditionalExecutionQueue$ExecutionRunner.runExecution(DefaultConditionalExecutionQueue.java:187)
at org.gradle.internal.work.DefaultConditionalExecutionQueue$ExecutionRunner.access$700(DefaultConditionalExecutionQueue.java:120)
at org.gradle.internal.work.DefaultConditionalExecutionQueue$ExecutionRunner$1.run(DefaultConditionalExecutionQueue.java:162)
at org.gradle.internal.Factories$1.create(Factories.java:31)
at org.gradle.internal.work.DefaultWorkerLeaseService.withLocks(DefaultWorkerLeaseService.java:264)
at org.gradle.internal.work.DefaultWorkerLeaseService.runAsWorkerThread(DefaultWorkerLeaseService.java:128)
at org.gradle.internal.work.DefaultWorkerLeaseService.runAsWorkerThread(DefaultWorkerLeaseService.java:133)
at org.gradle.internal.work.DefaultConditionalExecutionQueue$ExecutionRunner.runBatch(DefaultConditionalExecutionQueue.java:157)
at org.gradle.internal.work.DefaultConditionalExecutionQueue$ExecutionRunner.run(DefaultConditionalExecutionQueue.java:126)
... 2 more

Environment:

com.android.tools.build:gradle:8.3.1

Any ideas what is happening here? It kind of sounds like there is something wrong with the library-packaging itself.. but thats just a guess and in fact i could open the renamed jar with a zip-tool myself.

cheers,

Jerg

Labels (1)
0 Karma

Jerg_Weick
Explorer

That's great news @Ryan.Paredez,

thx for keeping me updated!

I'm looking forward to the 24.4 release.

Cheers,

Jerg

0 Karma

iamryan
Community Manager
Community Manager

Hi @Jerg.Weick,

Thanks for your patience, Eng has confirmed it's a bug and is expected to be fixed in 24.4. Which should hopefully be by mid-May.

0 Karma

iamryan
Community Manager
Community Manager

Hi @Jerg.Weick,

I've shared this with the PM, and it's being investigated whether it's a bug. I will report back here when I have any new information.

^ Posted was edited by @Ryan.Paredez to correct my initial reply. 

0 Karma

Jerg_Weick
Explorer

Hi @Ryan.Paredez ,

thanks for the heads up. I'll keep an eye on the thread.

cheers,

Jerg

0 Karma
Get Updates on the Splunk Community!

Splunk Observability Cloud's AI Assistant in Action Series: Auditing Compliance and ...

This is the third post in the Splunk Observability Cloud’s AI Assistant in Action series that digs into how to ...

Splunk Community Badges!

  Hey everyone! Ready to earn some serious bragging rights in the community? Along with our existing badges ...

What You Read The Most: Splunk Lantern’s Most Popular Articles!

Splunk Lantern is a Splunk customer success center that provides advice from Splunk experts on valuable data ...