maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stuart McCulloch <>
Subject Re: Maven Central Opinion
Date Sun, 05 Jan 2014 14:36:08 GMT
On 5 Jan 2014, at 13:15, Tommy Svensson <> wrote:

> I was asked to submit one of my opensource tools at github to maven central. This turned
out to be a rather complex procedure.

[ disclaimer: I work at Sonatype ]

Any suggestions for improving the process are welcome - most of the requirements below are
actually more recommendations / effects of the maven-release-plugin workflow, so maybe we
need to clarify this on the wiki.

> Sonatype puts the following requirements on anyone wanting to submit to maven central:
> - You are forced to set a Sonatype pom as parent of your project and thus inherit things
you have no control over. 

The wiki recommends a parent pom with the relevant distributionManagement (so Maven knows
where to deploy artifacts) plus some release configuration for adding sources, javadoc, signatures,

You can always use a different parent pom and copy the distributionManagement section across
- feel free to ask for help with this, and we can always add a section to the wiki if others
would find this useful

> - You are forced to have a SNAPSHOT version even if you have no use for such.

This is the standard Maven release workflow - you don’t strictly need this if you’re just
uploading releases, just go to the existing tagged release and use “mvn deploy”

(you’ll need override the deploy properties on the command line ie.
if your pom doesn’t point to OSSRH)

> - You are forced at submission time to select a new version for your software even if
you have no idea if it will be a minor, bugfix or new functionality at this point in time.

As above, you can always deploy an existing release - either with “mvn deploy” or by packaging
it up as a bundle and uploading it using the UI:

However, once you have released an artifact to central its content should never change

> - Your public repository (github, etc) which you are forced to point out in your pom
are no longer yours to decide over. It will be updated during the submission process. 

That’s the Maven release plugin - it updates the released pom so it points to the right
tagged release, then changes it back for development

Some projects do releases differently by using the versions plugin to update the poms, tagging
the release manually, then finally using “mvn deploy"

> - After running 3 different mvn commands you also need to login to Sonatypes nexus server
and ”release” the artifacts before the become available. 

That’s so you can check the uploaded artifacts before they get distributed to central, mirrors,
and from there to developers machines - because once a release is on central its content should
never change

If you want to skip this step then you can by configuring the nexus-staging-maven-plugin which
can help manage the staging workflow:


You can also use this plugin to access the same staging commands available to you through
the Nexus UI (or you could even use the underlying REST API if you wish)

Finally depending on your project there are alternative routes to central, such as
for Apache projects, or the new service. 

> The idea of the maven repository that has grown larger than maven itself is a completely
brilliant idea. It takes open source to a new level where anyone can just depend on other
open source code and automatically download it on build. This is really good for the open
source world (well, at least the Java/JVM part of it) . The fact that the release process
to this central repository is far too complex, I see as a really great problem, inhibiting
the easy sharing of open source work. I have often found open source tools and frameworks
that are not available in maven central, and that is because not everyone is willing to put
up with this, which now also includes myself. As I see it, either this procedure needs to
be changed to provide a trivial release of binary artifacts without affecting your poms, or
there need to be an alternative open repository providing ease of release, where it is trivial
for anyone to share their binaries for easy access by others. I’m wondering if I’m alone
in this view or if there are others who agree with me ? 
> Tommy Svensson
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message