It is not really the fault of this plugin, but the dependencies to various Maven artifacts bring in a ton of additional Jars transitively on the Gradle plugin classpath. It is difficult to maintain a clean Gradle plugin classpath by this and adding dependency verification data for all those Jars is challenging. Adding this plugin to a build (which successfully verified all its dependencies before) gives: 59 artifacts failed verification
There are two things I can think off to improve the situation:
- Add
excludes for everything that is not needed in the common case (e.g. listenablefuture-9999.0-empty-to-avoid-conflict-with-guava.jar is clearly not needed)
- Shadow dependencies in this plugin so that they become part of the artifact. This repository itself should then have a good dependency verification setup so that we make sure what we re-package is verified.
Doing something here, may help with issues like #65.
(Maybe updating to Maven 4.x as baseline also reduces the amount of transitives (?))
It is not really the fault of this plugin, but the dependencies to various Maven artifacts bring in a ton of additional Jars transitively on the Gradle plugin classpath. It is difficult to maintain a clean Gradle plugin classpath by this and adding dependency verification data for all those Jars is challenging. Adding this plugin to a build (which successfully verified all its dependencies before) gives:
59 artifacts failed verificationThere are two things I can think off to improve the situation:
excludesfor everything that is not needed in the common case (e.g.listenablefuture-9999.0-empty-to-avoid-conflict-with-guava.jaris clearly not needed)Doing something here, may help with issues like #65.
(Maybe updating to Maven 4.x as baseline also reduces the amount of transitives (?))