I'm afraid this is the expected behavior for how Maven 2.0.x treats version numbers.
You hit on the problem at the end when you noted "versions are compared as strings." For the versions you cite-
126.96.36.199 and 188.8.131.52-maven does compare these as strings and 184.108.40.206 is considered newer than 220.127.116.11. Ergo, the range "[18.104.22.168,22.214.171.124)" is invalid for the same reason "[2,1)" would be: the version on the left is newer than the one on the right.
Here's the ugly details. Maven recognizes versions that match the following pattern:
A is the Major Version,
B is the Minor Version,
C is the Incremental Version (also known as Bug Fix),
D is the Build Number, and
'foo' is the Qualifier.
A, B, C, and D, are compared numerically and the qualifier is a string compare. A version may only have a build number or a qualifier, not both. The numbers are considered zero if not present i.e., 1.1 is the same as 1.1.0 and 1.1-0.
Here's the important part: any version not matching this pattern is treated entirely as a String.
Here is the relevant part of org.apache.maven.artifact.versioning.VersionRange:
if ( upperVersion != null && lowerVersion != null && upperVersion.compareTo( lowerVersion ) < 0 )
throw new InvalidVersionSpecificationException( "Range defies version ordering: " + spec );
Here is a test using org.apache.maven.artifact.versioning.DefaultArtifactVersion:
public void testMng3010()
String s1 = "126.96.36.199";
String s2 = "188.8.131.52";
DefaultArtifactVersion v1 = new DefaultArtifactVersion(s1);
DefaultArtifactVersion v2 = new DefaultArtifactVersion(s2);
assertTrue( s1.compareTo(s2) > 0 ); // 184.108.40.206 > 220.127.116.11 as Strings ...
assertTrue( v1.compareTo(v2) > 0 ); // ... and as maven versions
If you have control over how this project tracks its version, consider changing it to a more Maven-friendly pattern. If not, you'll have to find another way of dealing with the issue e.g., just picking one and omitting the range entirely.