openrewrite / rewrite-gradle-plugin

OpenRewrite's Gradle plugin.
Apache License 2.0
65 stars 41 forks source link

Created Gradle configurations are consumable and declarable at the same time, it will eventually only be possible to be one of these #239

Open vlsi opened 1 year ago

vlsi commented 1 year ago

What version of OpenRewrite are you using?

org.openrewrite.rewrite.gradle.plugin:6.4.3

How are you running OpenRewrite?

plugins {
    id("org.openrewrite.rewrite")
}

dependencies {
    rewrite(platform("org.openrewrite.recipe:rewrite-recipe-bom:2.4.1"))
    rewrite("org.openrewrite.recipe:rewrite-static-analysis")
}

rewrite {
    activeRecipe("org.openrewrite.java.OrderImports")
    activeRecipe("org.openrewrite.staticanalysis.MissingOverrideAnnotation")
}

What did you expect to see?

No deprecation warnings should appear

What did you see instead?

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.

Are you interested in contributing a fix to OpenRewrite?

I might probably work on that.

I believe https://github.com/openrewrite/rewrite-gradle-plugin/blob/0daa455128fe26ab97e1754adc23e1b55b931445/plugin/src/main/java/org/openrewrite/gradle/isolated/DefaultProjectParser.java#L694-L699 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.

The same goes for detached configurations in https://github.com/openrewrite/rewrite-gradle-plugin/blob/0daa455128fe26ab97e1754adc23e1b55b931445/plugin/src/main/java/org/openrewrite/gradle/ResolveRewriteDependenciesTask.java#L94

timtebeek commented 1 year ago

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!

shanman190 commented 1 year ago

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;.

vlsi commented 1 year ago

Does it really make sense spending time on Gradle 4 support now? Of course, it is your choice, but Gradle 4 is quite old

shanman190 commented 1 year ago

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.