-
Notifications
You must be signed in to change notification settings - Fork 78
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
spring-cloud-dependencies
upgrade drops commons-collections4
version
#556
Comments
I've tried replicating this issue with a unit test, but so far no luck. Any indications of what's needed to reproduce the issue? import org.junit.jupiter.api.Test;
import org.openrewrite.DocumentExample;
import org.openrewrite.config.Environment;
import org.openrewrite.test.RecipeSpec;
import org.openrewrite.test.RewriteTest;
import static org.assertj.core.api.Assertions.assertThat;
import static org.openrewrite.java.Assertions.mavenProject;
import static org.openrewrite.maven.Assertions.pomXml;
class CommonsCollections4VersionTest implements RewriteTest {
@Override
public void defaults(RecipeSpec spec) {
spec
.recipe(Environment.builder()
.scanRuntimeClasspath("org.openrewrite.java.spring")
.build()
.activateRecipes("org.openrewrite.java.spring.boot3.UpgradeSpringBoot_3_3")
);
}
@Test
@DocumentExample
void retainCommonsCollections4Version() {
rewriteRun(
mavenProject("project",
//language=xml
pomXml(
"""
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.example</groupId>
<artifactId>fooservice</artifactId>
<version>1.0-SNAPSHOT</version>
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.0.0.RELEASE</version>
<relativePath/>
</parent>
<properties>
<commons-collections4.version>4.4</commons-collections4.version>
</properties>
<dependencies>
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-collections4</artifactId>
<version>${commons-collections4.version}</version>
</dependency>
</dependencies>
</project>
""",
spec -> spec.after(actual -> {
assertThat(actual)
.containsPattern("<version>3.3.\\d+</version>")
.contains("<version>${commons-collections4.version}</version>");
return actual;
})
)
)
);
}
} |
Hi Tim - my composite recipe is based on
along with custom recipes of my own divising. The initial state of the pom reference a parent spring boot version of I'll start by removing the custom ones to see if it makes any difference to the outcome. Also - if it helps adding the two seemingly unnecessary recipe calls prevents the problem occuring: new RemoveDependency("org.apache.commons", "commons-collections4", "compile"),
new AddDependency("org.apache.commons", "commons-collections4", "${commons-collections4.version}",
null, "compile", null, null, null,
null, null, null, null), |
In this issue there are two things going on:
I restricted my recipe run to just using the OpenRewrite standard Spring Boot upgrade recipes and got the following results:
Which suggests something different in the 3_2 upgrade recipe and/or organisation of managed dependencies in the ancestor poms. |
Thanks for the detailed look! My first hunch was to look at differences in the Spring Boot managed dependencies, but I don't see commons-collections4 there at all 😕
How are you testing there? Because even when I change the unit test to work from 2.7.0 and upgrade to 3.2.x I do not see the test fail. |
Yes I don't think I've bottomed out exactly what is happening.Maybe the Spring Boot version is a red herring and commons-collections4 is being pulled in by another dependency (possibly spring cloud). |
OK - I think I can see what's going on. Prior to running the recope, my pom also declared a dependencyManagement section for spring-cloud: <properties>
...
<spring-cloud.version>2021.0.3</spring-cloud.version>
<properties>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-dependencies</artifactId>
<version>${spring-cloud.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement> After running the I think at this point the standard O/R recipe determined that the When I added back in my custom pom recipe, that included this: new ChangePropertyValue("spring-cloud.version", "2023.0.3", true, null) and it looks like this newer version of spring cloud no longer has a managed dependency for Does that sound like a reasonable explanation, and if so is there anything I can do in my recipe short of a manual RemoveDependency/AddDependency step to restore the fully-versioned I wondered if I should be using |
Thanks fro narrowing that down! With that suggestion I can now finally replicate that dropped version this with a unit test based on Line 43 in e5589ab
@Test
@Issue("https://github.com/openrewrite/rewrite-spring/issues/556")
void upgradeSpringCloudVersion() {
rewriteRun(
mavenProject("project",
//language=xml
pomXml(
"""
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.example</groupId>
<artifactId>fooservice</artifactId>
<version>1.0-SNAPSHOT</version>
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.2.2.RELEASE</version>
<relativePath/>
</parent>
<properties>
<java.version>11</java.version>
<spring-cloud.version>Hoxton.SR9</spring-cloud.version>
<mockito.version>2.18.3</mockito.version>
<commons-collections4.version>4.4</commons-collections4.version>
</properties>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-dependencies</artifactId>
<version>${spring-cloud.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-collections4</artifactId>
<version>${commons-collections4.version}</version>
</dependency>
</dependencies>
</project>
""",
spec -> spec.after(actual -> {
assertThat(actual)
.containsPattern("<version>3.3.\\d+</version>")
.containsPattern("<spring-cloud.version>2023.0.\\d+</spring-cloud.version>")
.contains("<version>${commons-collections4.version}</version>");
return actual;
})
)
)
);
} This now fails with
|
It's getting a bit late to think through what we should be doing here, but welcome to help explore the proper fix here. |
spring-cloud-dependencies
upgrade drops commons-collections4
version
I think I finally narrowed it down to a change between these two versions:
That dependency managed version was introduced a couple years before
We've then got multiple levels of What we fail to do is reintroduce the dependency version when the dependendy becomes unmanaged again. We do that when changing the parent; I'm thinking we lack that when changing (nested?) The above means we can likely reproduce this on a lot smaller scale in openrewrite/rewrite using just the recipes that made changes here:
|
As reported on Slack by @wabrit
The text was updated successfully, but these errors were encountered: