rewrite icon indicating copy to clipboard operation
rewrite copied to clipboard

Publish a `rewrite-bom` Maven BOM

Open jkschneider opened this issue 2 years ago • 14 comments

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.

jkschneider avatar Mar 31 '22 22:03 jkschneider

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)

yeikel avatar Apr 02 '22 15:04 yeikel

Partially solved by #1537. Now just need one more module rewrite-all (?) that takes first order dependencies on all modules.

jkschneider avatar Apr 08 '22 01:04 jkschneider

@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 avatar Apr 10 '22 03:04 shanman190

@shanman190 We'd want a separate rewrite-all from this repo that also includes all recipe jars.

jkschneider avatar Apr 12 '22 15:04 jkschneider

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>

shanman190 avatar Apr 14 '22 04:04 shanman190

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>

shanman190 avatar Apr 14 '22 15:04 shanman190

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 ?

yeikel avatar Apr 14 '22 15:04 yeikel

@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)

shanman190 avatar Apr 14 '22 16:04 shanman190

@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)

Thank you for taking the time to explain. It makes sense

yeikel avatar Apr 15 '22 03:04 yeikel

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.  

yeikel avatar Apr 27 '22 14:04 yeikel

I think that my issue is that I had to remove it from the plugins and just add them as normal dependencies

yeikel avatar Apr 27 '22 14:04 yeikel

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.

tkvangorder avatar Apr 27 '22 23:04 tkvangorder

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?

yeikel avatar Apr 28 '22 02:04 yeikel

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.

shanman190 avatar Apr 28 '22 02:04 shanman190

We have been published rewrtie-bom and rewrite-recipe-bom for a while now, closing defunct issue

sambsnyd avatar Dec 23 '22 18:12 sambsnyd