1

I want to build a library as a Maven project that depends on some Spring libraries (version 3).

I want this to be used in projects that are also using Spring 3 - but I don't want the versions to clash, otherwise we'll have both versions of the spring libraries on the classpath.

I want to get the minor version for my library pom.xml from the enclosing project.

My question is: Is it possible to have a Maven library that inherits a dependency minor version from the enclosing project?

heenenee
  • 19,914
  • 1
  • 60
  • 86
hawkeye
  • 34,745
  • 30
  • 150
  • 304

2 Answers2

2

I believe you are worrying about something that is not going to happen. Conflicting versions between different dependencies on the same artifact will be resolved by a process called dependency mediation, and Maven will not pull in multiple versions of the same artifact onto the same classpath. E.g., if you make your library your-group:your-library:1.0 depend on org.springframework:spring-context:3.2.4.RELEASE, and my project my-group:my-artifact:1.0 depends on both org.springframework:spring-context:3.1.4.RELEASE and your-group:your-library:1.0, then Maven will only pull version 3.1.4 of spring-context into my build, not both 3.1.4 and 3.2.4. If your library also depends spring-beans:3.2.4 and there happens to exist some incompatibility between spring-context:3.1.4 and spring-beans:3.2.4, then you can consider it the responsibility of my project to add spring-beans as a dependency and explicitly override its version to 3.1.4 in my-artifact's POM.

That being said, you can sort of accomplish what your question is directly asking by using version ranges:

<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-context</artifactId>
    <version>[3.0.0.RELEASE,3.2.16.RELEASE]</version>
</dependency>

This will effectively tell projects depending on your library that your library is okay with any existing 3.X version of spring-context, but version ranges have their own set of rules during dependency mediation that can possibly be unfriendly and obscure, and they won't link up between different artifacts either, so I would recommend just sticking with a regular version number in your case.

Community
  • 1
  • 1
heenenee
  • 19,914
  • 1
  • 60
  • 86
0

Not really, no.

Are you happy to declare variables in the parent pom for this purpose? If not, then you'll have to create variables in your project pom or in a new parent pom that inherits from the enclosing project. ${project.version} and ${project.parent.version} aren't built from other variables and you can't compose/decompose them; you would need to duplicate those values into other variables and build your version string from those variables.

And even when you do that, maven will complain about version not being a constant.

The normal pattern in this case is to completely ignore the parent version and maintain your project's version independently: just because your project uses Spring 3 doesn't mean that it shouldn't start at version 1. You can manually track the parent version if you want to. Since your project is not part of the parent project, the maven convention of omitting ${project.version} and inheriting it from the parent project is probably not appropriate.

Paul Hicks
  • 13,289
  • 5
  • 51
  • 78