views:

859

answers:

7

I'm interested in maintaining a Maven 2 repository for my organization. What are the some of the pointers and pitfalls that would help.

What are guidelines for users to follow when setting up standards for downloading from or publishing their own artifacts to the repository when releasing their code? What kinds of governance/rules do you have in place for this type of thing? What do you include about it in your developer's guide/documentation?

UPDATE: Answers so far have discussed technology options for the repository, but any suggestions or recommendations w.r.t how you work with the repository? Things like repository groups, external repository proxying, etc.?

+3  A: 

Perhaps this is obvious, but, for reproducibility, developers should never overwrite artifacts, they should be new versions.

This also applies to upstream repositories. If you download Apache-commons version 1.2.3, you should really never download it again. Fixes come from latter versions, not applied to existing versions.

altCognito
Thanks for the clarification - I meant this in the context of using the release plugin to publish a version of an artifact that they themselves own to the repository. Will edit the question.
cwash
+1  A: 

Use Artifactory.

stevedbrown
Good advice! +1
André
Why? What advantage does it provide over alternatives?
cwash
It's just simple to use and free. Nexus limits features for the free version, but if that's not a concern (either the feature set which isn't that different or the free part), it's good too. I dropped the 'Definitely', that's a little too strong as altCognito called me on.
stevedbrown
I wouldn't say Nexus limits features, there are additional features in the Pro version, but most of those are Enterprise features which simply don't exist in any other tool.
Brian Fox
+6  A: 

Definitely use Nexus. :P

I've used both Nexus and Artifactory. The interface for Nexus is a lot more robust, it's a lot more configurable, and of course, written by Sonatype, who repesents pretty much everything Maven well.

That being said, Artifactory is decent and workable.

altCognito
Can you explain the types of features that make it robust/configurable at a birds-eye level?
cwash
Thanks for the links!
cwash
Anyone got an idea if any of these tools can also maintain an Ivy repo?
skaffman
@skaffman Any of them should be able to as Ivy has the built-in capability to read Maven 2 repositories. I can personally verify Nexus and Archiva functioning well with Ivy.
Ophidian
Ant and Ivy themselves are deploying to the Nexus repo at Apache, so there are definitely no issues with Ivy/Nexus integration.
Brian Fox
+3  A: 

I am using Artifactory myself, and love the user interface and ease of deployment/maintenance. That said, I have never used Nexus, and cannot really help you with a proper feature comparison.

Here are some things off the top of my head that I really like about Artifactory (keep in mind Nexus may have these features too):

  1. Nice Web 2.0 interface.
  2. The ability to import your local Maven repository to help get you started.
  3. Ease of integration with existing LDAP servers for security (I'm a big fan of a single repository for storing credentials).

Given that there's really only two major Maven Repository implementation out there, if you really want to make sure you've made the right choice, I'd recommend trying both out, and deciding for yourself which you like better.

Jack Leow
Thanks for weighing in on the Artifactory vs. Nexus choice... I agree the best approach will be trying both out. Do you have any advice regarding using one specifically? Also, has your organization run into any bumps or roadblocks?
cwash
No specific advice really, it was so simple that there really wasn't much to it. We have not run into any issues at all with Artifactory.
Jack Leow
+2  A: 

Something else to consider:

http://archiva.apache.org/

Brad
and this: http://www.sonatype.com/people/2009/07/from-apache-archiva-to-sonatype-nexus/
Brian Fox
Oh a "case study" on a sonatype blog, how impartial. Why don't you just link to the product and let people make their own minds up.
Brad
Arnaud wrote that blog and originally posted it on his personal site, in French. We just asked him to translate to English. How is that partial?
Brian Fox
+2  A: 

As the the ORIGINAL QUESTION (technical issues to consider when constructing a M2 repository), I would recommend creating read-only user for browsing the repository and administrative user per administrator (that said: one read-only user for all those users that are not administrators). Moreover, I would recommend generating backup images periodically (once a day perhaps ?). Very important both if your repository is big or you install your own artifacts from time to time.

Last, but not least, when adding new remote repositories, you must add inclusion/exclusion filters so an artifact lookup in the repository would be done more quickly.

There are lots of other issues to consider, but these are the leading issues I've encountered while managing a Maven internal repository.

For the record, I'm using both Nexus and Artifactory; I can clearly state that while Nexus is very simple and operative (though I sometimes have problems with the installation process on Ubuntu), its free version cannot compete with Artifactory's community (free) edition. Excluding Artifactory's awesome web 2 UI, its main features, such as security management, periodic backups, and accessibility issues are way beyond those of Nexus.

Guy
+7  A: 

I would recommend setting up one nexus server with at least four repositories. I would not recommend artifactory. The free version of nexus is perfectly fine for a dev team of less than 20 in less than three groups. If you have more users than that, do yourself a favor and pay for the Sonatype release. The LDAP integration pays for itself.

  1. Internal Release
  2. Internal Snapshot
  3. Internal 3rd Party for code used in house that comes from outside sources, or for endorsed 3rd party versions. Put the JDBC drivers, javax.* stuff and stuff from clients and partners here.
  4. External Proxies common proxy for all the usual sources like m2, codehaus etc

Configure Nexus to do the following for internal repos

  1. Delete old Snapshots on regular intervals
  2. Delete Snapshots on release
  3. Build index files. This speeds up local builds too

Have a common settings.xml file that uses these four and only these four sources. If you need to customize beyond this try to keep a common part of the settings file and use profiles for the differences. Do not let your clients just roll their own settings or you will end up with code that builds on one machine but not on any other machine.

Provide a common proxy for your clients. In Nexus, you can add a bunch of proxies to the common Maven sources (Apache, JBoss, Codehaus) and have a single proxy exposed to the internal clients. This makes adding and removing sources from your clients much easier.

Don't mix Internal and 3rd party artifacts in the same repository. Nexus allows you to add jars to an internal repository via a web gui. I recommend this as the way of adding your JDBC drivers and other external code to 3rd party. The UI is quite nice to use when compared to most enterprise software.

Define a common parent POM that defines the Internal snapshot and release repos via the distributionManagement tag. I know lots of people tell you not to do this. And while I freely admit that there are all kinds of problems with doing this, it works out OK if the clients will only be building releases and snapshots to be deployed to a single internal repository.

If you have an existing mis-managed Maven repository, create a 5th repos called Legacy and put the whole repos there. Set up a cron task to delete old files from legacy once they are a year old. That gives everyone a year to move off of it and update their poms.

Establish an easy to stick to naming convention for internal artifacts. I prefer GroupID of Department.Function.Project and an ArtifactId for that componentName. For internal repositories, com/org/net and the company name are likely to be irrelevant. And wrong if the company changes its name. It is far less likely that the sales, accounting or inventory department will be renamed.

sal
Great advice, thanks.
cwash
As an update, Sonatype opensourced their LDAP support for Nexus with the 1.5 release at the beginning of 2010.
Ophidian