Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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 this issue Nov 7, 2023 · 4 comments
Labels
bug Something isn't working parser-gradle

Comments

@vlsi
Copy link

vlsi commented Nov 7, 2023

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

Configuration rewriteImplementation = subproject.getConfigurations().maybeCreate("rewrite" + sourceSet.getImplementationConfigurationName());
rewriteImplementation.extendsFrom(implementation);
Set<File> implementationClasspath;
try {
implementationClasspath = rewriteImplementation.resolve();
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

Configuration detachedConf = project.getConfigurations().detachedConfiguration(dependencies);

@vlsi vlsi added the bug Something isn't working label Nov 7, 2023
@timtebeek
Copy link
Contributor

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
Copy link
Collaborator

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
Copy link
Author

vlsi commented Nov 7, 2023

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
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working parser-gradle
Projects
Status: Backlog
Development

No branches or pull requests

3 participants