Baseline task reports a failure due to a circular resolution #6445
Comments
|
Thinking about this and the JavaDoc shows a misunderstanding which I have encountered before. For some reason, it tries to add the current project as a default dependency, expecting to obtain the previous release's jar as an artifact to resolve against. However, since this is a dependency within the gradle subproject that produces that maven coordinate, Gradle rewrites it to a project dependency. The exact version is ignored since Gradle always selects the most recent version in the dependency set, which is the current project. Therefore the variant selection fails because it cannot satisfy that version range with the project dependency. You might assume this would not happen on the build plugin phase, since the compile phase should be independent from the project's own dependency set. That sadly is not the case, as I found with the ErrorProne static analyzer which replaces the java compiler with its extension. As that library depends on Caffeine for its AST cache, this is rewritten to a project dependency and causes a failure since Caffeine cannot be compiled without having itself be built for the compiler. The workaround, as acknowledged by the Gradle team, is to exclude the dependency and instead put an opaque file dependency by downloading the jar manually to satisfy it at execution time. Therefore, Caffeine includes a download phase to bootstrap the javac compiler with the previous version. I believe a similar issue is happening here by believing that the current project's buildScript phase can resolve the prior version. It won't and will transparently be rewritten to a project dependency, and then fail the strictly constraint. When it fails, presumably the baseline just can't leverage the prior version as an optimization. The simplest and correct solution would be to remove this optimization attempt and not depend on a prior release. |
|
You have any concrete advice how to make this work for you? |
|
Yes, I believe the defaultDependencies can never succeed and does not help this plugin. If removed it would avoid an error appearing in the problem report. |
I noticed in Gradle's Problem Report this error, which I have narrowed down to coming from bnd.
When using
--debugthe error is from thebaselinetask trying to resolve the project itself as a dependency.The detachedConfiguration appears to be run before the task is executed but rather when it is being added to the execution graph ("realizing" the task). The error is ignored at configuration time and, due to the jar task dependency, at execution time this works fine. I believe the problem is your usage of
defaultDependencieswhere you try to resolve the project prematurely. Typically a default dependency is for an external tool version and letting the user override that, e.g. if a 3rd party plugin for a tool defaults to an older version because it is not released in tandem. I'm unsure why the defaults would be needed here, rather than resolving them as part of your task execution. Or maybe at least filter out the current project itself? It just doesn't make sense to me to have circular logic where the baseline task depends on the project's release jar in order to build the release jar.bnd/gradle-plugins/biz.aQute.bnd.gradle/src/main/java/aQute/bnd/gradle/BndBuilderPlugin.java
Lines 99 to 131 in 2c97dfd
The text was updated successfully, but these errors were encountered: