views:

36

answers:

3

Maven 2.2.1 claims to support version ranges (see e.g. http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sect-project-dependencies.html#pom-relationships-sect-version-ranges)

I tried from a brandnew maven installation the following pom:

<project>

  <modelVersion>4.0.0</modelVersion>
  <artifactId>rangetest</artifactId>
  <groupId>my.group</groupId>
  <version>1.0</version>
  <packaging>jar</packaging>

  <description>test project containing one dependency, only</description>
  <dependencies>
   <dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <version>4.8</version>
    <scope>test</scope>
   </dependency>
  </dependencies>
 </project>

The dependency should resolve to junit 4.8.2, right? But instead, the version 4.8 is resolved:

C:\Users>mvn dependency:tree
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'dependency'.
[INFO] ------------------------------------------------------------------------
[INFO] Building Unnamed - my.group:rangetest:jar:1.0
[INFO]    task-segment: [dependency:tree]
[INFO] ------------------------------------------------------------------------
[INFO] [dependency:tree {execution: default-cli}]
[INFO] my.group:rangetest:jar:1.0
[INFO] \- junit:junit:jar:4.8:test
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 2 seconds
[INFO] Finished at: Thu Oct 07 14:30:40 CEST 2010
[INFO] Final Memory: 9M/23M
[INFO] ------------------------------------------------------------------------

You might think it's an issue with Junit, as 4.8 is an existing version, but it's not. In my projects, I have versions deployed from 1.0.0 to 1.0.15 (no version 1.0!), but mvn dependency:tree complains about missing artifact of version 1.0.

+1  A: 

That only works if you actually specify a version range. You use 4.8 which is a single version number, so Maven tries to resolve it directly. A version range must start with [ or ( (inclusive and exclusive, respectively).

In your case, try: [4.8,4.9)

Aaron Digulla
Well, Maven range spec http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-DependencyVersionRanges makes a difference between "hard" requirements (e.g. [4.8]) and a "soft" requirement (like 4.8 without brackets). What's the use of soft requirements, then?
Jay
@Jay: Never heard of the term. `4.8.1` selects just that version and nothing else. My guess is that the document is outdated.
Aaron Digulla
@Aaron Yes, maybe another sad example for Maven's poor documentation. Do you know of any better reference for the version stuff?
Jay
soft requirements work like they should. when resolving dependencies and there is a conflict between version, the best one is choosen if at most one of them is a hard requirement. see the note at the end of the link in your question.
Salandur
+1  A: 

There doesn't seem to be a range qualifier in your version tag. Maybe you meant to use the following to require version 4.8 or later:

<version>[4.8,]</version>
Philipp Jardas
+2  A: 

If you want to use version ranges, specify a version range as others pointed out. Currently, you're not.

But my real advice would be to not use version ranges at all, version ranges are a bad idea for build reproducibility and the last thing you want is a build that suddenly starts to fail because of an unknown reason. Just don't, they are a bad practice (which is probably why version ranges aren't documented anymore).

Pascal Thivent
(+1) here's my last vote for today :-) BTW, who made this CW and why?
seanizer
agreed, unless you want to use bugfixversion automaticly. but is a pain in the ass...
Salandur
@seanizer: It's either the OP (only the OP can make his own question CW) or the system after 7/8(?) edits. But in this case, it's the OP as we can see in the revision history. Probably a "mistake" but the OP is new here.
Pascal Thivent
@Pascal yes, figured that.
seanizer