Put maven artifacts in central Maven repository

[GoogleCodeExporter]

There are a couple reasons why this is critical and why hosting your own 
Maven repository is not really a good option.

Firstly, as of now (Mon March 1st, 1:42 PM EST) your Maven repository is 
down and is breaking my production build because I cannot access it from my 
build machine. If your artifacts were in central this would not happen as 
one of several mirrors with good uptime would be chosen.

Secondly, projects which have dependencies on your library and themselves 
want to be hosted in central will be restricted from doing so because 
central (rightly) has a policy against third-party non-official repository 
definitions in the POM for hosted artifacts. 

Luckily, it is now rather easy to get your artifacts into the Maven central 
repository through the SonaType Open Source Repository Hosting project.  
See https://docs.sonatype.com/display/NX/OSS+Repository+Hosting  

The people there are quite helpful, and it is worth the trouble to get your 
artifacts hosted, as it increases usage and decreases friction with 
potential end users. I have gone through this process myself with my 
project, jmemcached, and would be willing to help you along, if you want.

Original issue reported on code.google.com by ryan.daum on 1 Mar 2010 at 6:46

[GoogleCodeExporter]

As of 16:45 EDT, your repository is again not answering HTTP requests, 
preventing 
access and slowing down builds.

Original comment by ryan.daum on 29 Mar 2010 at 8:59

[GoogleCodeExporter]

We have been talking about this recently, and want to improve things.  I think 
we'll
be able to put a bit of effort into this soon.  

Thanks much for the offer of help on setting this up.  We may well take you up 
on
this.  Are your artifacts built by Maven, or using something else?

Original comment by ingen...@gmail.com on 30 Mar 2010 at 5:45

[GoogleCodeExporter]

Hi,

FYI, there is a fork that provide a mavenized build for spymemcached (and add 
SLF4J as 
default logging fwk) : http://github.com/yaourt/java-memcached-client-slf4j

Hope this could help

Original comment by thomas.s...@gmail.com on 31 Mar 2010 at 2:43

[GoogleCodeExporter]

Re: help setting this up, my builds are using Maven, but as long as you are 
providing 
a valid POM with all the right stuff in it (license, etc. etc.) and are GPG 
encoding 
your artifacts the OSSRH process is the same.

That said I personally don't see the advantage of maintaining a non-Maven build 
for 
spymemcached. I mavenized it myself a year or so ago and there was nothing in 
there 
that didn't fit easily into a standard Maven2 build. 

Original comment by ryan.daum on 31 Mar 2010 at 2:47

[GoogleCodeExporter]

Ryan,

While it's very important that all users are able to integrate the code 
seamlessly into their projects, it's not very 
important to me to throw away things that I consider important in replacing a 
working build tool that requires me to do 
more work for less just so a file can be downloaded from a web server.

To begin to respond to your statement about not seeing the advantage of 
maintaining a non-maven build, consider the 
alternative from my perspective.

Here's one part that I dislike:  The mvn release plugin wants to operate the 
SCM for you -- it wants to tag.  I don't like 
how it tags.  My tags currently look like this:  
http://pastebin.com/spam.php?i=1vQnC78C

Important points:

* List of changes
* List of contributors
* List of bugs fixed
* GPG signature on the tag ensuring cryptographic certainty of the source

Also, I have a tool that goes through my list of tags to generate my changelog: 
 http://dustin.github.com/java-
memcached-client/changelog.html

I give up all of those things with the mvn release tool *and* I have to edit 
and commit a file just to set my version 
number.  Right now, I just write a tag, which is exactly the same as the 
release notes, and then I do a build and move it 
into place.

But yes, we do intend to make it easier for you to consume this, and I'm 
certainly open to having more than one way for 
developers to do builds.  Releasing code through maven just does not seem to 
make sense.

Original comment by dsalli...@gmail.com on 1 Apr 2010 at 6:22

[GoogleCodeExporter]

(sorry for the strange wrapping -- google's browser isn't getting along with 
google's 
other services very well the last couple of days)

Original comment by dsalli...@gmail.com on 1 Apr 2010 at 6:24

[GoogleCodeExporter]

This is possible, and maybe even practical without too much hassle.  Should be 
investigated.

http://dustin.github.com/2010/04/01/why-not-maven.html

Original comment by ingen...@gmail.com on 24 Sep 2010 at 1:58

• Added labels: Milestone-Release3.0, Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

buildr is updated and has maven 2 support, so will try to fix this proper

Original comment by ingen...@gmail.com on 20 Apr 2011 at 6:16

• Added labels: Milestone-Release2.6
• Removed labels: Milestone-Release3.0

[GoogleCodeExporter]

Complete: 
http://files.couchbase.com/maven2/

Original comment by ingen...@gmail.com on 8 Jun 2011 at 10:49

• Changed state: Verified