Superfluous version tags added to all dependencies, when one dependency can not be resolved
When upgrading a project to Spring Boot 2.7 (2.7.8 at the moment) results in a version tag inserted into every Spring Boot dependency in the pom.xml file, which should not be the case, since the parent defines that version already:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
becomes
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
<version>2.7.8</version>
</dependency>
Hi @martinlippert ; Could you tell me a bit more about the version and recipe that you used? Because I'm having trouble replicating the issue here. I downloaded a Maven 2.7.x starter project; manually downgraded that to 2.7.7.
https://start.spring.io/#!type=maven-project&language=java&platformVersion=2.7.8&packaging=jar&jvmVersion=17&groupId=com.example&artifactId=demo&name=demo&description=Demo%20project%20for%20Spring%20Boot&packageName=com.example.demo&dependencies=actuator
Then I ran the following command to perform a Spring Boot upgrade within the 2.7.x range.
mvn org.openrewrite.maven:rewrite-maven-plugin:4.39.0:run \
-Drewrite.recipeArtifactCoordinates=org.openrewrite.recipe:rewrite-spring:4.32.0 \
-DactiveRecipes=org.openrewrite.java.spring.boot2.UpgradeSpringBoot_2_7
Which only changed the parent version property for me to 2.7.8, as I would expect; no superfluous version
Notice that I'm using the plugin & rewrite-spring versions released a few days ago; we are still updating the documentation.
Let me double check the latest version, I was probably using the previous one due to that being integrated into the tooling on our side.
Double checked with the latest release, looks all good... :-)
Glad to hear & thanks for confirming!
Hey @timtebeek, I am re-opening this issue since I came across this again (using the latest 4.32.0 release of rewrite-spring) and I think I found the circumstances under which this problem appears.
I am using the upgrade recipe to upgrade a petclinic sample project that also has the mysql connector as a dependency. Due to 4.32.0 not having the fix for this yet, the result of the upgrade is a somewhat broken pom, since the dependency to the mysql connector can't be resolved anymore. In this situation, the superfluous versions get added to all the dependencies in the pom.xml file, as observed when filing this issue.
When I remove the dependency to the mysql connector before running the upgrade recipe, the superfluous version tags are NOT added to the dependencies, so it seems to be related to the fact that the resulting pom.xml file is not fully resolving correctly anymore.
Since the problem of upgrading the dependency to the changed mysql coordinates is already fixed, this concrete case doesn't seem to be an issue anymore moving forward. But I think situations like this might occur in the future again (or when users have random dependencies on their projects that cause the upgraded pom file to not resolve anymore) and the superfluous version tag should not get inserted here. So probably worth fixing the underlying issue here - at least from what I guess at the moment... :-)
WDYT?
Hi Martin; thanks for the detailed analysis once again; good to know the circumstances that contribute to this issue. I've updated the title of the issue, and indeed, while it only occurs slightly off the happy path, it's something for the backlog given the unfortunate effect.
This is still a problem. Even though the dependency update of the mysql connector is working now as expected, having this dependency on the pom.xml makes the additional and annoying version tags appear after upgrading petclinic to SB3.
When I remove the mysql connector from the dependency list before I execute the upgrade, the additional version tags are not being added.
I think this is quite an important issue, since introducing these superfluous and annoying additional version tags needs to be removed manually again. They can't live on in the project for various obvious reasons, so looking into this and having a fix for this would be awesome.
(cc @BoykoAlex)
Seeing this issue again, now related to ehcache, also on spring petclinic when going from 2 to 3.

I have a similar issue in which version tags are inserted into managed dependencies. I made a PR that should fix this. Currently some of the used UpgradeDependencyVersion are configured to overwrite managed dependency versions. This imho should never be done for Spring dependencies as they are managed by a Spring parent or by a Spring bom.
@martinlippert https://github.com/openrewrite/rewrite-spring/commit/9f4bced5c61c34e0e5d95dbdef00452e922b627a should at least reduce this issue for Spring Boot projects; is that also what you would expect and can confirm on your end?
It's not a structural fix to the behaviour in the presence of unknown dependencies, but might at least hide the effects on Spring such that we can close the issue here.