Enforcing valid dependency versions

One of the aspects of the Central Repository we have strived for is to continuously raise the bar required for components deployed to and distributed by the Central Repository. A long time ago, you could just deploy to any top-level namespace - now we enforce that you control the namespace by owning the domain name and similar means. Other steps that proved to be extremely useful over the years are e.g., requiring javadoc and sources, requiring signatures and validating various aspects of the content of the pom file. The desire for these changes has always come from the community of users and if you look at other repositories like the NuGet Gallery or npmjs.org, you will see similar patterns.

Background

The POM file is the container of all the meta-data about your project including mundane things like name, description or URL for your project web site, but also other very applicable and useful information such as the URL of your CI server or your mailing list as well as details about the source code locations and connections. The POM file is the project object model as used by Apache Maven natively and widely understood by other build tools and a crucial part of the Maven repository format used by the Central Repository. The dependency information in the POM is extremely important, since it allowed a build tool independent determination of transitive dependencies for a specific component. The power of the declarative and automated download and management of dependencies, no matter what your build tool is, hinges on this declaration.

Unfortunately we found out recently, that there are some invalid configurations sneaking in. Specifically we found components that declare versions of their dependencies using the Apache Ivy syntax for selecting the latest sub-revision. E.g. a version of 16.+ has a meaning of any version from 16 up to anything smaller than 17 . These could be e.g. 16.3. Using such a syntax breaks the dependency mechanism of all other build systems and as such has to be avoided. Members of the Android Maven community have alerted us to problems caused by the usage of this invalid syntax.

A new rule

We have already worked together with the Gradle and Android community directly (thanks Hans and Xav!) to ensure that the translation to the standard POM file in Gradle correctly translates to a Maven range syntax. It is following the standard mathematical range syntax, which is widely supported by all build systems consuming components from the Central Repository and its downstream repositories. We have also reached out to the Maven and the SBT community to arrive at a consensus for next steps.

With this post we want to also notify all other communities, that we will be enforcing that no version of any dependency declaration in the pom uses this syntax or the 'latest' variant also possible in Ivy. Specifically the staging rule that validates the POM file has been updated by myself in cooperation with the Nexus Repository Manager team. The next deployment of Nexus Repository Manager (the upcoming 2.11 release) to OSSRH scheduled for middle to end of November, will include that rule and enforce this next level of quality.

What do to?

Unless you are using version strings using the + symbol at the end or starting with 'latest' with Gradle 2.2 or lower, there is nothing to do. You might be affected if you are using SBT although we had to reports of such problems. Ivy seems not to be affected. In case you are using such a syntax, you just need to translate it to mathematical range syntax or a fixed version. E.g. you could change from 16.+ to [16,17) . Future version of Gradle will even automate that behavior for you!

How can you help?

Please spread the word about this new requirement. Notify any projects affected by this change, so they have a chance to fix this before their next release build. If you are a member of an affected tool's community or open source project, please fix it on your project and also check that the projects you depend on are behaving correctly.

Next steps

Once the rule goes into production, we will as usual be available for any help required. And if you find any other issues with components in the Central Repository, please let us know. We all rely on it being a high quality repository and can only tackle it as a community effort.

Thank you for your help.

Sonatype Ops Team