You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The configuration :benchmarks:jandexClasspath is both resolvable and consumable. This is considered a legacy configuration and it will eventually only be possible to be one of these.
The configuration :benchmarks:jandexClasspath is both consumable and declarable. This combination is incorrect, only one of these flags should be set.
The configuration :benchmarks:jmh is both resolvable and consumable. This is considered a legacy configuration and it will eventually only be possible to be one of these.
The configuration :benchmarks:jmh is both consumable and declarable. This combination is incorrect, only one of these flags should be set.
The configuration :benchmarks:rewrite is both resolvable and consumable. This is considered a legacy configuration and it will eventually only be possible to be one of these.
The configuration :benchmarks:rewrite is both consumable and declarable. This combination is incorrect, only one of these flags should be set.
The configuration :benchmarks:rewriteimplementation is both resolvable and consumable. This is considered a legacy configuration and it will eventually only be possible to be one of these.
The configuration :benchmarks:rewriteimplementation is both consumable and declarable. This combination is incorrect, only one of these flags should be set.
The configuration :benchmarks:rewritejmhImplementation is both resolvable and consumable. This is considered a legacy configuration and it will eventually only be possible to be one of these.
The configuration :benchmarks:rewritejmhImplementation is both consumable and declarable. This combination is incorrect, only one of these flags should be set.
The configuration :benchmarks:rewritetestImplementation is both resolvable and consumable. This is considered a legacy configuration and it will eventually only be possible to be one of these.
The configuration :benchmarks:rewritetestImplementation is both consumable and declarable. This combination is incorrect, only one of these flags should be set.
> Task :postgresql:rewriteResolveDependencies
Caching disabled for task ':postgresql:rewriteResolveDependencies' because:
Caching has not been enabled for the task
Task ':postgresql:rewriteResolveDependencies' is not up-to-date because:
Task has not declared any outputs despite executing actions.
The configuration :postgresql:detachedConfiguration2 is both resolvable and consumable. This is considered a legacy configuration and it will eventually only be possible to be one of these.
The configuration :postgresql:detachedConfiguration2 is both consumable and declarable. This combination is incorrect, only one of these flags should be set.
The configuration :postgresql:detachedConfiguration2 is both resolvable and consumable. This is considered a legacy configuration and it will eventually only be possible to be one of these.
The configuration :postgresql:detachedConfiguration2 is both consumable and declarable. This combination is incorrect, only one of these flags should be set.
should be adjusted. implementation is not meant to "resolve" dependencies, and it is supposed to declare dependencies only.
If one needs a "classpath", they should inherit from compileClasspath or something like that.
In any case, the generated configuration should be marked with isCanBeConsumed = false; isCanBeResolved = true as the configuration is not meant for consumption by other modules.
Thanks a lot for the detailed report and offer to help address the problem. I lack some background here myself, but @sambsnyd or @shanman190 can maybe weigh in on your suggested approach, and help review once we get to that stage. Let us know if you need any help!
For the first case, I think using compileClasspath directly would result in identical behavior and remove they deprecation. The only caveat is I don't remember if there's a variant that supports Gradle 4.x of that outside of compile.
For the second use case, I agree that it's easiest to just swap those to isConsumable = false; isResolvable = true;.
So to explain that part, it's not uncommon for an enterprise organization to be lagging way behind. The Gradle 4 target was set such that it gave the best possibility of supporting enterprise customers where they were already at and then using migration recipes to modernize their portfolio rapidly.
It's a balancing act in terms of choosing an archaic Gradle minimum versus being unable to support a prospective customer.
What version of OpenRewrite are you using?
org.openrewrite.rewrite.gradle.plugin:6.4.3
How are you running OpenRewrite?
What did you expect to see?
No deprecation warnings should appear
What did you see instead?
Are you interested in contributing a fix to OpenRewrite?
I might probably work on that.
I believe
rewrite-gradle-plugin/plugin/src/main/java/org/openrewrite/gradle/isolated/DefaultProjectParser.java
Lines 694 to 699 in 0daa455
implementation
is not meant to "resolve" dependencies, and it is supposed to declare dependencies only.If one needs a "classpath", they should inherit from
compileClasspath
or something like that.In any case, the generated configuration should be marked with
isCanBeConsumed = false; isCanBeResolved = true
as the configuration is not meant for consumption by other modules.The same goes for detached configurations in
rewrite-gradle-plugin/plugin/src/main/java/org/openrewrite/gradle/ResolveRewriteDependenciesTask.java
Line 94 in 0daa455
The text was updated successfully, but these errors were encountered: