Maven parsing fails for managed dependency entries without version tag
See original GitHub issueParsing a (surprisingly valid) pom like the below (with assertions enabled) causes the parser to throw an exception.
<?xml version="1.0" encoding="UTF-8"?>
<project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd" xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<modelVersion>4.0.0</modelVersion>
<groupId>test</groupId>
<artifactId>test</artifactId>
<version>1.0-SNAPSHOT</version>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>com.fasterxml.jackson</groupId>
<artifactId>jackson-bom</artifactId>
<version>2.11.1</version>
<scope>import</scope>
<type>pom</type>
</dependency>
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-core</artifactId>
<!-- no version! -->
</dependency>
</dependencies>
</dependencyManagement>
</project>
java.lang.AssertionError
at org.openrewrite.maven.internal.RawMavenResolver.processDependencyManagement(RawMavenResolver.java:158)
at org.openrewrite.maven.internal.RawMavenResolver.processTask(RawMavenResolver.java:131)
at org.openrewrite.maven.internal.RawMavenResolver.resolve(RawMavenResolver.java:114)
at org.openrewrite.maven.internal.RawMavenResolver.resolve(RawMavenResolver.java:99)
at org.openrewrite.maven.internal.RawMavenResolver.resolve(RawMavenResolver.java:77)
at org.openrewrite.maven.MavenParser.parseInputs(MavenParser.java:90)
at org.openrewrite.Parser.parse(Parser.java:39)
Issue Analytics
- State:
- Created 2 years ago
- Comments:5 (3 by maintainers)
Top Results From Across the Web
maven dependency without version - Stack Overflow
It is impossible for maven to work without defining versions of the artifacts. They should be defined somewhere in dependencyManagement tag ...
Read more >Apache Maven Dependency Plugin – Usage
Use stripVersion to remove version from default file name. This field is ignored when artifactId.destFileName is set. Use artifactItem.
Read more >Properties in pom are not resolved for maven-install-plugin #256
Hi, I try to use the Git commit hash (and the commit timestamp) as the version number for my built artifact. mvn package...
Read more >Maven dependencyManagement vs. dependencies Tags
As we can see, there is not any version tag present in our later dependency tag. Surprisingly, it's valid syntax, and it can...
Read more >Spring Boot Reference Documentation
Build systems: Maven | Gradle | Ant | Starters. Best practices: Code Structure | @Configuration | @EnableAutoConfiguration | Beans and Dependency Injection.
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Hi @danielnorberg. Thanks for the report and all the explanation. I’ve removed the assert and a couple later checks as well that assumed that there would be a version. In addition, wrote a cleanup recipe for Maven that does what I suppose you want to do as well, which is to remove these
dependencyManagement
dependencies which have no versions.It is available to run as
org.openrewrite.maven.cleanup.DependencyManagementDependencyRequiresVersion
.Thanks again!
I have yet to spot a valid use of this maven behavior in the wild. In our case we encountered pom files written like this (likely due to mistakes, probably not intentional) in internal repositories and I wanted to make our automated pom refactoring tool (built using openrewrite, operating daily on thousands of repositories) fix these pom files by removing dependency management entries without version tags.
In fact I only noticed that openrewrite asserts that version tag is present when adding automated tests (that run with assertions enabled) to our refactoring tool to cover this use case. With assertions disabled parsing seems to complete successfully (although I haven’t verified that the result is “correct”).