Getting Started
Tutorials & Guides
Reference
Concepts & Explanations
Design Partners
Automating Maven Dependency Management
Search, Organize, and Refactor your Maven poms
Dependency management is a complex and often frustrating part of software development. Sometimes a transitive dependency you'd never expect makes it onto your runtime classpath. Sometimes your build tool resolves a conflict between requested dependency versions in an unexpected way. Despite the headaches, it wouldn't make sense for most projects to forgo dependencies.
OpenRewrite can help. In this tutorial, we'll learn how to automate common dependency management tasks by migrating a project from one slf4j implementation to another.
Currently, OpenRewrite's dependency management capabilities are only implemented for the Maven build tool. If you are interested in dependency management for Gradle keep an eye on this issue on our roadmap.
Setup
- 1.
- 2.Familiarize yourself with the basics of applying the rewrite-maven-plugin as described in our quickstart guide.
The sample spring-petclinic project is based on an older version of the project that requires a JDK version 1.8 to build. Newer JDK versions will not work. Get OpenJDK 8 here if you do not already have one.
Getting Insight into your Dependencies
The first step in changing your dependencies is knowing what they are. Let's find out which of the existing dependencies are using logback-classic. There's no mention of logback in the pom.xml itself, but any of the dependencies that are there could be bringing it in transitively.
Add the rewrite-maven-plugin to the pom.xml:
pom.xml
1
<!-- inside of project/build/plugins -->
2
<plugin>
3
<groupId>org.openrewrite.maven</groupId>
4
<artifactId>rewrite-maven-plugin</artifactId>
5
<version>4.17.2</version>
6
<configuration>
7
<activeRecipes>
8
<recipe>com.yourorg.LogbackInsight</recipe>
9
</activeRecipes>
10
</configuration>
11
</plugin>
Copied!
Then create a rewrite.yml file at the project root with these contents:
rewrite.yml
1
---
2
type: specs.openrewrite.org/v1beta/recipe
3
name: com.yourorg.LogbackInsight
4
displayName: Find Logback Usage
5
recipeList:
6
- org.openrewrite.maven.search.DependencyInsight:
7
groupIdPattern: ch.qos.logback
8
artifactIdPattern: "*"
9
scope: compile
Copied!
Now run
mvn rewrite:dryRun. This won't make changes to the project's files. It will produce a rewrite.patch file in the reports directory, with a link in the console log:Console Log
1
These recipes would make changes to pom.xml:
2
org.openrewrite.maven.search.DependencyInsight
3
Report available:
4
/mnt/f/Projects/openrewrite/spring-petclinic-migration/target/site/rewrite/rewrite.patch
5
Run 'mvn rewrite:run' to apply the recipes.
Copied!
Use your preferred diff viewer to inspect the
rewrite.patch file, which reveals all of the dependencies that transitively depend on logback.
At this point, you have all of the information you need to manually exclude logback-classic from those other dependencies and add a dependency on your preferred slf4j implementation. But that wouldn't prevent logback-classic from being added back in the future. There is an easier, future-proof way to do it.
Switching SLF4J Implementations
Use the rewrite recipes ExcludeDependency and AddDependency to ensure that only your preferred slf4j dependency is used. If a new transitive dependency on logback-classic appears in the future, ExcludeDependency will detect and exclude it.
Add this to your rewrite.yml:
rewrite.yml
1
---
2
type: specs.openrewrite.org/v1beta/recipe
3
name: com.yourorg.UseSlf4jSimple
4
displayName: Use slf4j Simple
5
recipeList:
6
- org.openrewrite.maven.ExcludeDependency:
7
groupId: ch.qos.logback
8
artifactId: logback-classic
9
- org.openrewrite.maven.AddDependency:
10
groupId: org.slf4j
11
artifactId: slf4j-simple
12
version: 1.7.X
Copied!
And set the
com.yourorg.UseSlf4jSimple recipe as active in your pom.xml:pom.xml
1
<!-- inside of project/build/plugins -->
2
<plugin>
3
<groupId>org.openrewrite.maven</groupId>
4
<artifactId>rewrite-maven-plugin</artifactId>
5
<version>4.17.2</version>
6
<configuration>
7
<activeRecipes>
8
<recipe>com.yourorg.UseSlf4jSimple</recipe>
9
</activeRecipes>
10
</configuration>
11
</plugin>
Copied!
You can now run
mvn rewrite:dryRun again to preview the changes that will be made and mvn rewrite:run to apply the changes.
Exclusions for logback-classic added everywhere it was being brought in transitively
New dependency on slf4j-simple
No explicit version number is added for slf4j-simple because an appropriate version is set by the project's parent pom. AddDependency is smart enough not to add the unnecessary version number.
CI Integration
mvn rewrite:dryRun only produces warnings in the console output and a rewrite.patch file if there are active recipes that would make changes. This means dryRun can be used in your CI pipeline to prevent new logback-classic dependencies from being added going forward. Configure the CI step to fail if dryRun emits any warnings to the console log, or if a rewrite.patch file is produced, and you have an effective guard against regression.Of course, CI failures are always at least a little bit frustrating for developers. Another option, at least in organizations where the commit is made by CI, is to run
mvn rewrite:run before the build & test step. Then the build won't need to fail because rewrite will automatically fix the dependency problem.Next Steps
The dependency management recipes used in this guide aren't the only such recipes included in rewrite. See the Maven recipe reference for the full listing of dependency management recipes.
Tutorials & Guides - Previous
Refactoring with Declarative YAML Recipes
Next - Tutorials & Guides
Running Rewrite without build tool plugins
Last modified 8d ago
Export as PDF
Copy link