search

openrewrite / rewrite-gradle-plugin

OpenRewrite's Gradle plugin.
Apache License 2.0
61 stars 38 forks source link

Output used OpenRewrite version #199

Open koppor opened 1 year ago

koppor commented 1 year ago

When I run the task rewriteRun, the output is as follows:

Starting a Gradle Daemon, 1 busy and 2 incompatible and 1 stopped Daemons could not be reused, use --status for details

> Configure project :
Project : => 'org.jabref' Java module

> Task :compileJava
Hinweis: Einige Eingabedateien verwenden oder ├╝berschreiben eine veraltete API.
Hinweis: Wiederholen Sie die Kompilierung mit -Xlint:deprecation, um Details zu erhalten.
Hinweis: Einige Eingabedateien verwenden nicht geprüfte oder unsichere Vorgänge.
Hinweis: Wiederholen Sie die Kompilierung mit -Xlint:unchecked, um Details zu erhalten.

> Task :compileTestJava
Warnung: Modulname in --add-reads-Option nicht gefunden: org.kordamp.ikonli.IkonHandler
Warnung: Modulname in --add-reads-Option nicht gefunden: org.kordamp.ikonli.IkonProvider
Warnung: [options] Modulname in --add-exports-Option nicht gefunden: org.junit.jupiter.engine
Hinweis: Einige Eingabedateien verwenden oder ├╝berschreiben eine veraltete API.
Hinweis: Wiederholen Sie die Kompilierung mit -Xlint:deprecation, um Details zu erhalten.
3 Warnungen

> Task :compileJmhJava
Hinweis: C:\git-repositories\jabref-all\jabref\src\jmh\java\org\jabref\benchmarks\Benchmarks.java verwendet oder ├╝berschreibt eine veraltete

API.
Hinweis: Wiederholen Sie die Kompilierung mit -Xlint:deprecation, um Details zu erhalten.

> Task :rewriteRun
Validating active recipes
Parsing sources from project JabRef
All sources parsed, running active recipes: org.jabref.config.rewrite.cleanup, org.openrewrite.java.logging.slf4j.ParameterizedLogging, org.openrewrite.java.logging.slf4j.Slf4jLogShouldBeConstant

Deprecated Gradle features were used in this build, making it incompatible with Gradle 9.0.

You can use '--warning-mode all' to show the individual deprecation warnings and determine if they come from your own scripts or plugins.

See https://docs.gradle.org/8.1.1/userguide/command_line_interface.html#sec:command_line_warnings

BUILD SUCCESSFUL in 1m 5s
16 actionable tasks: 6 executed, 10 up-to-date

There is no output the used OpenRewrite version.

Today, the minor version of the gradle plugin and OpenRewrite match, but the major version does not. Thus, they seem to develop independently:

image

image

I keep being asked, which version I should use. (E.g., https://github.com/openrewrite/rewrite-static-analysis/issues/91#issuecomment-1536419775 and https://github.com/openrewrite/rewrite-logging-frameworks/issues/102#issuecomment-1535904147) I cannot easily find out.

Two wishes:

rpau commented 1 year ago

From the build logs, it seems that you are using Gradle, and therefore you should be able to know what plugin dependencies version are resolved using ./gradlew buildEnvironment.

Is this command not resolving which openrewrite version are you using?

koppor commented 1 year ago

I am taking the view of a non-gradle expert. I am using gradle since mroe than 10 years (https://github.com/koppor/gradlepackage/commits/master), but never executed buildEnvironment. Thank you for educating me in that regard. -- Maybe, other gradle novices also don't know about that command, but are trying to use OpenRewrite.

For me following output only indicates that I configured OpenRewrite "somewhat" correctly. It is not a full validation, because (at leats) UseAsBuilder is not validated fully (see https://github.com/openrewrite/rewrite-static-analysis/issues/90 for details).

Validating active recipes
Parsing sources from project JabRef
All sources parsed, running active recipes: org.jabref.config.rewrite.cleanup, org.openrewrite.java.logging.slf4j.ParameterizedLogging, org.openrewrite.java.logging.slf4j.Slf4jLogShouldBeConstant

Excerpt from the output:

\--- org.openrewrite.rewrite:org.openrewrite.rewrite.gradle.plugin:5.40.4
     \--- org.openrewrite:plugin:5.40.4
          +--- org.openrewrite:rewrite-bom:7.40.3

From https://github.com/openrewrite/rewrite-static-analysis/issues/17 I can learn that the configuration needs to be somehow as follows:

dependencies {
    rewrite(platform("org.openrewrite.recipe:rewrite-recipe-bom:1.12.1"))
}

However, the current dependency is on org.openrewrite:rewrite-bom. Should try that.

Nevertheless, I think, the README.md should state how a user can use a specific version of OpenRewrite. "specific" especially includes a version not available when the gradle plugin was released.

shanman190 commented 1 year ago

@koppor, the reference that you're seeking is the Gradle Plugin configuration documentation which you can find here:

https://docs.openrewrite.org/reference/gradle-plugin-configuration

There are actually 3 possible ways that the rewriteVersion is determined:

The first one provides the defaults that the plugin assumes, the second only only effects the rewrite proper version, and the third effects the entire rewrite ecosystem.

From a logging out the version in use, that's easy for options 1 and 2 because the plugin is responsible for the configuration itself, but becomes a bit harder for option 3 because Gradle is responsible for it.

rpau commented 1 year ago

I am glad to see that the command I suggested answers your question.

My understanding is that you would like to have documentation to understand how to overwrite the openrewrite version of a previous existing gradle plugin? Is that correct?

I agree that a developer might be an openrewrite user but not a gradle expert.

Would a solution that automatically releases the plugins when a new release of openrewrite avoid the need for overwriting the rewrite dependency?

Thanks for your honest feedback to improve openerwrite

shanman190 commented 1 year ago

You should also be able to see all the versions by doing:

gradle rewriteResolveDependencies dependencies --configuration rewrite

NOTE: the rewriteResolveDependencies is due to having to delay default dependencies for Gradle 4.0 support.

koppor commented 1 year ago

@koppor, the reference that you're seeking is the Gradle Plugin configuration documentation which you can find here:

Hey! I am a bit naive in using software. I am expecting important details in the README.md. The current README.md appears complete for the most important use cases (see https://github.com/openrewrite/rewrite-gradle-plugin#what-is-this).

Since I kept being asked which version I do use, I thought this would indicate that it should be very prominent in the documentation. IMHO the README.md is the first place to start for users quickly looking for guidance.

Sorry for not checking the linked documentation (which is now properly linked! Thanks to the team for fixing https://github.com/openrewrite/rewrite-gradle-plugin/issues/196) - and thank you for the pointer!

From a logging out the version in use, that's easy for options 1 and 2 because the plugin is responsible for the configuration itself, but becomes a bit harder for option 3 because Gradle is responsible for it.

There is no way to ask OpenRewrite via an API about its version and output that? 😅

koppor commented 1 year ago

There are actually 3 possible ways that the rewriteVersion is determined:

* The build receipt found in the plugin jar at `/rewrite/versions.properties`

* The `rewriteVersion` property on the `rewrite` extension object

Do you mean rewrite { in build.gradle? Then, I don't find any documentation on that: https://docs.openrewrite.org/reference/gradle-plugin-configuration?q=rewriteVersion

* By using a Gradle platform in the `rewrite` configuration (use `org.openrewrite.recipes:rewrite-recipes-bom`)

Link for me: https://mvnrepository.com/artifact/org.openrewrite.recipe/rewrite-recipe-bom/1.19.3

koppor commented 1 year ago

Would a solution that automatically releases the plugins when a new release of openrewrite avoid the need for overwriting the rewrite dependency?

Definitively! That would also enable semi-automatic updates using dependabot or similar tools!

timtebeek commented 1 year ago

This potentially ties into https://github.com/openrewrite/rewrite-docs/issues/186 which is asking about which versions of OpenRewrite are compatible with what versions of the plugins, and the resources bundled with the plugins that tell about the bundled versions.

From reading the above this issue has two possible solutions:

  1. Print the used versions (harder in some cases, as per https://github.com/openrewrite/rewrite-gradle-plugin/issues/199#issuecomment-1537163839)
  2. Automatically release the Maven and Gradle plugins when there's a new minor(?) release of OpenRewrite, such that there's always a compatible plugin version available.

Should we create a separate issue for the second solution? Or abandon the first solution and only focus on the second in this issue?

ia3andy commented 1 year ago

This potentially ties into openrewrite/rewrite-docs#186 which is asking about which versions of OpenRewrite are compatible with what versions of the plugins, and the resources bundled with the plugins that tell about the bundled versions.

From reading the above this issue has two possible solutions:

  1. Print the used versions (harder in some cases, as per Output used OpenRewrite version #199 (comment))
  2. Automatically release the Maven and Gradle plugins when there's a new minor(?) release of OpenRewrite, such that there's always a compatible plugin version available.

IMO 2. is required 👍 and make this info available somewhere (as said in the other issue) :)

Should we create a separate issue for the second solution? Or abandon the first solution and only focus on the second in this issue?

shanman190 commented 1 year ago
  1. Automatically release the Maven and Gradle plugins when there's a new minor(?) release of OpenRewrite, such that there's always a compatible plugin version available.

So one thing that I'd like to chime in here with is that at least for the Gradle plugin, rewrite proper is totally isolated into a child classloader, so from the plugin's standpoint you can often set the rewrite version (ie. rewriteVersion) many, many versions to either side of what the plugin's internal default is. This is of course with the exception of the rewrite 7.x -> 8.x release which changed the API signature of all Parser implementations or other times where we introduce a breaking change. This is all to say that a given rewrite-gradle-plugin is almost always compatible with it's paired rewrite major version. So I think releasing the build plugins is instead more about easing the accessibility of new rewrite versions when the user is using the internal default versions rather than one of compatibility.

As a result of the isolation and the ability to use rewriteVersion from the extension, it's not strictly guaranteed that if a user says that they are plugin version X that they are also on rewrite version Y.