Want to make sure I understand your current setup correctly. You have a local repository on a file system somewhere that contains all the artifacts approved for use in your builds. Then you create a copy of that repository and point Hudson to that private copy. Is that one copy per project built? Or do all builds on Hudson use that private repo?
Anyway, we used an older version of a particular repo manager a few years back but switched over to the Professional version of Nexus last fall. We too need to lock down what versions of artifacts developers use and Nexus has worked well for that. Not knowing your environment or process, I'm not sure if these would benefit you, but thought I would share the benefits we've seen: - Nexus Staging Suite - This was probably the main reason we went with Nexus Pro. When we do a release build, we can intercept the artifact(s) and segregate them in a staging repository. If they do not pass testing or QA, we can "drop" the whole repo and those artifacts are gone. If everything passes, we can "release" the contents of the staging repo to our "production approved" repository. Helps ensure an artifact is not made available for general use until it's passed everything and has been formally released. It's worked well with our particular release process. - Nexus Procurement Suite - This has been a handy feature on those occasions when we do need to update our external artifacts, such as a new version of a plugin. Helps control how new external artifacts are introduced inside the company. - Search capabilities - The UI provides a nice capability for searching for an artifact. Has some cool features where we can drill into the contents of a particular version of a jar or easily get the XML of the GAV for an artifact so we can paste it into our POM. Can search on part of a GAV or even a class name to find artifacts containing a particular class. - Repository Grouping - We can create group repositories in Nexus that are configured to use several individual repositories. We can then use different profiles with Maven to point to different groups. So our CI builds in development can point to one group and our release builds can point to a different group. - Consistent repos used by both developers and the CI servers - Not sure how your developers build. Do they point at the same local repo as Hudson or are they looking external when they build local? We have each developer's Maven settings file configured to point to Nexus as well so there are no surprises when the code builds on Hudson as far as missing dependency versions, etc. Again, situation might differ for you and this is not intended to be a sales pitch for Nexus - I'm sure other Repository Managers have similar functionality as well - just sharing our experiences. Hope it helps. Dave Bruley Lead Technical Analyst CoreLink Administrative Solutions -----Original Message----- From: Sony Antony [mailto:[email protected]] Sent: Wednesday, April 20, 2011 8:03 AM To: Maven Users List Subject: Re: Advantages of using a Repository Manager Thank you for the link. I had looked at this section from teh book around a year back. I couldnt find any clear advantage since we have a pre approved and pre decided list of plugins and dependencies. Currently we have a master repository which is populated only when project decides to add a new dependency or plugin. At teh initial hudson setup, this repository is copied to a private location, and hudson is pointed to this private location ( this is one time only and is not done with each build ). Build is done in the offline maven mode. Given this scenario, Im trying to see if repository managers can provide any advantage over what we already have. --sony 2011/4/20 Tamás Cservenák <[email protected]> > See here for reasons: > > > http://www.sonatype.com/books/nexus-book/reference/sect-repoman-reasons.html > > > Thanks, > ~t~ > > On Wed, Apr 20, 2011 at 2:23 PM, Sony Antony <[email protected]> > wrote: > > > Im trying to evaluate whether we should use a repository manager. > > > > Will somebody post at least a few of the advantages here > > Our project uses a list of pre approved ( and pre downloaded ) > dependencies > > and plugins. > > > > --sony > > > Confidentiality Notice: This communication and any attachments are for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure, distribution or copying is prohibited. If you are not the intended recipient(s), please contact the sender by replying to this e-mail and destroy/delete all copies of this e-mail message. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
