Unable to resolve dependencies due to + sign in version number

[Download]

I am using this library through Maven but it has issues resolving dependencies when there is a + symbol in the version numbers.

The error I'm getting is:

Could not resolve dependencies for project XXXX: Failure to find org.picketbox:picketbox:jar:4.+ in http://repo.maven.apache.org/maven2 was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates are forced -> [Help 1]

The PBKDF2 pom.xml in Maven Central has such + symbols in it:

<dependency>
    <groupId>org.picketbox</groupId>
    <artifactId>picketbox</artifactId>
    <version>4.+</version>
    <scope>compile</scope>
</dependency>
<dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <version>4.+</version>
    <scope>test</scope>
</dependency>

This practice has apparently been 'outlawed' by Sonatype because it was breaking peoples builds.

Thank you for building a great library!

[Download]

The workaround I'm using is to manually include the dependency to picketbox and force the version that comes included with my WildFly installation:

<dependency>
    <groupId>org.picketbox</groupId>
    <artifactId>picketbox</artifactId>
    <version>4.0.21.Final</version>
    <scope>compile</scope>
</dependency>

[AlexBischof]

You are right. I was not aware of that and will create a PR.

[AlexBischof]

PR created

[Download]

Thank you!

[m9aertner]

Hello, thanks for bringing this up! Indeed the plus notation crept in since I come from an Ivy background. I will update this, sure.

But how? Fixing to one specific version, respectively, as @AlexBischof suggests in the pull request is one possible solution. But this does not truly reflect the intention? The dependency is so thin that indeed any version out of that "4.+" range (Ivy) works. Now the correct "Maven"-style representation of the current intention would be "[4,5)", in both cases picketbox and junit.

I'd have to test, ideally, that the code still compiles and tests OK with all possible (currently existing) matching junit:junit and org.picketbox:picketbox versions. Uh, this will better be automated, or we go for a more specific version indication: "[4.0.21,5)" which would then cover 4.0.21, 4.1.x and 4.9.x.

What do you think?

[m9aertner]

In order to build, sign and upload to Maven Central we'll have to bump the version number here to 1.1.1: difference in content or dependencies -> needs different version number.

[Download]

@m9aertner Actally, as far as the Maven build is concerned, it doesn't really matter. All the versions are in Maven Central anyway. The point is that they want a reliable, reproducible build so that everytime you build you get exactly the same output. Since it is a compile-time dependency the referenced JAR won't be included with the app and the version from the server will be used instead (which of course should be compatible with the one we compile against, but not necesarilly the same version).

The version I picked is the one that comes with the release of WildFly that I'm working on. I think it may actually be a good choice as it's one of the last patch releases of the lowest major/minor combinations (4.0) so it's in the spirit of your 4.+

[Download]

"I'd have to test, ideally, that the code still compiles and tests OK with all possible (currently existing) matching junit:junit and org.picketbox:picketbox versions."

I don't think that is in the spirit of semantic versioning... The makers of those libraries know (or should know :) whether they broke backwards compatibility for client code (major version number bump) or implementers (minor version number bump). The whole idea is that we don't have to test all versions because they did and would have bumped the version if they found incompatibilities.

I would just fix it to one compile-time version and be done with it. In practice usually the library ships with the EE container so if you really want to test you could test against some of the versions that ship with releases of JBoss etc.

[m9aertner]

Thanks all for the note and discussion!
Find v1.1.1 pushed to Maven Central, should appear there shortly.

[Download]

Great! Thank you!

[Download]

Ah I just see that you forgot to tag the release here in GitHub.... :)