Publish to maven central

[snuxoll]

Docopt.java should be published to the maven central repository for use by other applications.

[damiengiese]

Absolutely! I am (very slowly) working through the process now.

[hawkw]

+1

[mohammadsarhan]

+1

[kterry]

+1

[cosmin]

I opened issue #6 which might help with the process of getting things into Central.

[cosmin]

In the mean time I have pushed a version of this to Maven Central under the following information

<dependency>
  <groupId>com.offbytwo</groupId>
  <artifactId>docopt</artifactId>
  <version>0.6.0.20150202</version>
</dependency>

This should make it into Central on the next sync from OSSRH, so give it a couple of hours.

@damiengiese let me know if you need help with the process for getting this into Central under the official group ID, I've done this for a few other projects and I'm happy to answer any questions.

[selesse]

+1

[damiengiese]

@cosmin, thanks very much for your help. I've spent quite a lot of time learning about git and PGP in preparation to publish docopt to Maven Central, but I admit I've been hung up on updating the POM. It looks like you've added everything called out in the Maven Central Component Requirements, so that's a big help.

I'm still not sure that I understand how to perform a release using Maven, however. The technique you've provided (using the performRelease property) looks a little different than I've seen in the Sonatype documentation. Is this just a different way to do it, or is there some preferred way to perform a release? If so, can you point me to some documentation?

[cosmin]

@damiengiese the only difference between what they recommend and what I'm doing is that I am using the Maven release plugin rather the Nexus staging plugin. The release plugin takes care of a lot of house keeping for you. When working on a 1.0-SNAPSHOT for example, you would normally have to do the following tasks by hand:

1. remove the SNAPSHOT and use just 1.0
2. make sure there are no snapshot dependencies remaining, because that would make the build non-repeatable
3. check this in
4. tag the commit you just made
5. build from the tag and release
6. go back to master, and bump the version to the next development version (say 1.1-SNAPSHOT)

As you can see, this is a lot of work, and in my experience it's pretty hard to not screw this up when doing it by hand. Specifically most people end up tagging before they change the version to the release version and then you end up with a tag that is not what is actually built. Or they forget to bump the version to the next development version, etc.

So this is where the Maven release plugin comes in handy. It has two steps.

1. mvn release:prepare - which makes sure you can actually perform a release, the properties are set, the build passes, etc
2. mvn release:perform - actually performs the release which involves all of the above steps

When you use the release plugin, it sets the property performRelease by default, which is used to be able to activate other profiles during release. By having the release plugin auto-activate based on this property you don't have to remember to specify it with -Prelease when doing the release.

In newer versions of the maven release plugin they added a new configuration section called releaseProfiles which allows you to specify a list of profiles to activate when performing a release. This is the way that is now recommended by that guide, and rather than relying on the automatically set performRelease to auto-activate the release profile, it goes for the explicit route by doing

    <useReleaseProfile>false</useReleaseProfile>
    <releaseProfiles>release</releaseProfiles>

Which turns off the performRelease property and manually specifies the profile to activate on the second line. That should be a perfectly valid way to do it, it's just a newer way of using the release plugin and I guess I haven't caught up with the times.

If you feel more comfortable with that approach because of the documentation, I can update my pull request. But in either case, I highly recommend using the release plugin rather than doing manual releases.

[fsparv]

+1

[ansell]

+1

[plombardi89]

+1

[holgerbrandl]

I'd suggest to simply release it to jcenter https://bintray.com/bintray/jcenter instead. There you just need to package it along with the sources using

mvn  source:jar install

and you can upload the file via the web-interface.

[fsparv]

please? I'd like to use it but checking jars into git just stinks.

[holgerbrandl]

@fsparv what about the intermediate workaround of using

<dependency>
  <groupId>com.offbytwo</groupId>
  <artifactId>docopt</artifactId>
  <version>0.6.0.20150202</version>
</dependency>

as documented earlier in this thread?

[fsparv]

There now seem to be several versions published, and some folks appear to have stolen appropriate maven coordinates too... :( https://mvnrepository.com/search?q=docopt