rewrite
rewrite copied to clipboard
Publish a `rewrite-bom` Maven BOM
Just a BOM that lists all open source Rewrite jars known to be in a good state and in alignment with one another, so one dependency definition can pull them all.
We could do this for both releases and snapshots, where the mechanism to release a snapshot BOM could run on a schedule (e.g. daily) and use the Versions Maven Plugin to lock snapshot versions in advance of publishing.
This is a great idea
At the moment, I have four separate properties for each dependency that I am using :
<rewrite-maven-plugin.version>4.21.0</rewrite-maven-plugin.version>
<rewrite-logging-frameworks.version>1.4.0</rewrite-logging-frameworks.version>
<rewrite-testing-frameworks.version>1.19.0</rewrite-testing-frameworks.version>
<rewrite-migrate-java.version>1.3.0</rewrite-migrate-java.version>
And it is difficult to know if they're compatible
Additionally, I am also receiving updates for them individually (dependabot)
Partially solved by #1537. Now just need one more module rewrite-all
(?) that takes first order dependencies on all modules.
@jkschneider, so you're thinking a composite module with all rewrite modules being API dependencies?
Given this allows version alignment of all core rewrite modules and not all modules are required, is having a rewrite-all
for the purpose of those whom want to have all languages just included automatically?
@shanman190 We'd want a separate rewrite-all
from this repo that also includes all recipe jars.
This is now completed and awaiting releases.
Gradle
api(platform("org.openrewrite.recipe:rewrite-recipe-bom:latest.release"))
Maven
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.openrewrite.recipe</groupId>
<artifactId>rewrite-recipe-bom</artifactId>
<version>latest.release</version>
</dependency>
</dependencies>
</dependencyManagement>
For full transparency as well, there is a rewrite-bom
which provides version alignment of core rewrite modules. This is specifically helpful for consumption within the various recipe jars (including custom recipe jars) AND build plugins.
Gradle
api(platform("org.openrewrite:rewrite-bom:latest.release"))
Maven
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.openrewrite</groupId>
<artifactId>rewrite-bom</artifactId>
<version>latest.release</version>
</dependency>
</dependencies>
</dependencyManagement>
For full transparency as well, there is a
rewrite-bom
which provides version alignment of core rewrite modules. This is specifically helpful for consumption within the various recipe jars (including custom recipe jars) AND build plugins.Gradle
api(platform("org.openrewrite:rewrite-bom:latest.release"))
Maven
<dependencyManagement> <dependencies> <dependency> <groupId>org.openrewrite</groupId> <artifactId>rewrite-bom</artifactId> <version>latest.release</version> </dependency> </dependencies> </dependencyManagement>
For my own understanding, what will be the value for latest.release
?
A separate release for rewrite-bom
or the version of rewrite
?
@yiekel, for your particular above use case, you'll be adding the org.openrewrite.recipe:rewrite-recipe-bom
to your dependency management. It imports the rewrite-bom
as well as provides dependency management for all current and future rewrite recipe jars, so covers the full use case that you had from a version alignment standpoint.
I believe soon the release of rewrite-recipe-bom
will be available (I don't control the versions themselves, but they'll follow a standard release model and show up in maven central as they are completed), but with each update of rewrite proper, the update of a recipe jar, or the addition of a new recipe jar will result in a new version of the rewrite-recipe-bom
for you to consume with everything aligned. The openrewrite team will be able to provide more information as to what they are going to select for the release version of this new BOM.
To answer your second question, rewrite-bom
(the core one) will have the same version as other core modules (they're all published at the same time). rewrite-recipes-bom
will have a separate version number that aligns everything (as an example [as of this writing]: rewrite-bom:7.22.0, rewrite-spring:4.19.3, rewrite-testing-frameworks:1.20.2, etc)
@yiekel, for your particular above use case, you'll be adding the
org.openrewrite.recipe:rewrite-recipe-bom
to your dependency management. It imports therewrite-bom
as well as provides dependency management for all current and future rewrite recipe jars, so covers the full use case that you had from a version alignment standpoint.I believe soon the release of
rewrite-recipe-bom
will be available (I don't control the versions themselves, but they'll follow a standard release model and show up in maven central as they are completed), but with each update of rewrite proper, the update of a recipe jar, or the addition of a new recipe jar will result in a new version of therewrite-recipe-bom
for you to consume with everything aligned. The openrewrite team will be able to provide more information as to what they are going to select for the release version of this new BOM.To answer your second question,
rewrite-bom
(the core one) will have the same version as other core modules (they're all published at the same time).rewrite-recipes-bom
will have a separate version number that aligns everything (as an example [as of this writing]: rewrite-bom:7.22.0, rewrite-spring:4.19.3, rewrite-testing-frameworks:1.20.2, etc)
Thank you for taking the time to explain. It makes sense
Hi there, I tried this with latest release, so I have
<properties>
<openrewrite.recipe-bom.version>1.0.0</openrewrite.recipe-bom.version>
</properties>
<dependencyManagement>
<dependency>
<groupId>org.openrewrite.recipe</groupId>
<artifactId>rewrite-recipe-bom</artifactId>
<version>${openrewrite.recipe-bom.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
<dependencyManagement>
What version should I be using while declaring the plugins?
<plugin>
<groupId>org.openrewrite.maven</groupId>
<artifactId>rewrite-maven-plugin</artifactId>
<version>?</version>
<configuration>
</configuration>
<dependencies>
<dependency>
<groupId>org.openrewrite.recipe</groupId>
<artifactId>rewrite-logging-frameworks</artifactId>
<version>?</version>
</dependency>
<dependency>
<groupId>org.openrewrite.recipe</groupId>
<artifactId>rewrite-testing-frameworks</artifactId>
<version>?</version>
</dependency>
<dependency>
<groupId>org.openrewrite.recipe</groupId>
<artifactId>rewrite-migrate-java</artifactId>
<version>?</version>
</dependency>
</dependencies>
</plugin>
If I use openrewrite.recipe-bom.version
as the version then it downloads the wrong versions(for example 1.0 for rewrite-logging-frameworks) and If I do not declare a version, it fails to compile with
'build.plugins.plugin[org.openrewrite.maven:rewrite-maven-plugin].dependencies.dependency.version' for org.openrewrite.recipe:rewrite-logging-frameworks:jar is missing.
I think that my issue is that I had to remove it from the plugins and just add them as normal dependencies
I think the idea here is that you should not have to supply versions for the plugins OR dependencies, but we may have some more work to do before this works properly.
I suspect the versioning may not apply to the plugins (and probably needs to be added in pluginManagement
I will leave this issue open and move it to the next milestone.
I think the idea here is that you should not have to supply versions for the plugins OR dependencies, but we may have some more work to do before this works properly.
I suspect the versioning may not apply to the plugins (and probably needs to be added in
pluginManagement
I will leave this issue open and move it to the next milestone.
I was able to use it just declaring the plugin as dependencies with no versions and that seems to be doing the job
My only concern is that now the dependencies will be bundled with my jar instead of as a plugin dependency. Should I use a concrete scope?
So I personally don't use maven often, but apparently Maven doesn't support BOMs for plugins even though it's a heavily requested feature...
https://issues.apache.org/jira/browse/MNG-5588
@tkvangorder, you are correct. The intent for rewrite-bom
is to ensure consistent versioning for all projects built from this repository. The various recipe jars and build tool plugins are going to get updated to use rewrite-bom
to ensure version alignment for themselves in terms of the core rewrite projects that they consume. rewrite-recipe-bom
imports rewrite-bom
and recommends the versions for all recipe jars, so that everything is consistently controlled and aligned correctly in terms of what end users will import and use.
We have been published rewrtie-bom and rewrite-recipe-bom for a while now, closing defunct issue