You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
@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?
@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:
remove the SNAPSHOT and use just 1.0
make sure there are no snapshot dependencies remaining, because that would make the build non-repeatable
check this in
tag the commit you just made
build from the tag and release
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.
mvn release:prepare - which makes sure you can actually perform a release, the properties are set, the build passes, etc
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
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.
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.
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
Activity
damiengiese commentedon Sep 16, 2014
Absolutely! I am (very slowly) working through the process now.
hawkw commentedon Nov 3, 2014
+1
mohammadsarhan commentedon Jan 15, 2015
+1
kterry commentedon Jan 29, 2015
+1
cosmin commentedon Feb 3, 2015
I opened issue #6 which might help with the process of getting things into Central.
cosmin commentedon Feb 3, 2015
In the mean time I have pushed a version of this to Maven Central under the following information
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 commentedon Feb 25, 2015
+1
damiengiese commentedon Mar 15, 2015
@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
performReleaseproperty) 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 commentedon Mar 15, 2015
@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:
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.
When you use the release plugin, it sets the property
performReleaseby default, which is used to be able to activate other profiles during release. By having thereleaseplugin auto-activate based on this property you don't have to remember to specify it with-Preleasewhen doing the release.In newer versions of the maven release plugin they added a new configuration section called
releaseProfileswhich 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 setperformReleaseto auto-activate thereleaseprofile, it goes for the explicit route by doingWhich turns off the
performReleaseproperty 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 commentedon Apr 16, 2015
+1
ansell commentedon Aug 10, 2015
+1
plombardi89 commentedon Oct 30, 2015
+1
holgerbrandl commentedon Nov 11, 2015
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
and you can upload the file via the web-interface.
fsparv commentedon Mar 21, 2016
please? I'd like to use it but checking jars into git just stinks.
holgerbrandl commentedon Mar 23, 2016
@fsparv what about the intermediate workaround of using
as documented earlier in this thread?
fsparv commentedon Mar 31, 2023
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