Hi Sony, Glad it was helpful.
I'll try to clear up your questions on the staging suite. Short answer - the staging repositories contain our internal release candidate artifacts only. They do not contain any third party or external artifacts. Long answer: It's a feature in the professional version of Nexus that is used to make artifacts available in a segregated repository for functions such as QA before making them available for broader use. You set up configurations in Nexus to filter by Artifact ID or Group ID. When doing a maven deploy, Nexus will check the artifacts against the filters you configured, if any of the artifacts match, it dynamically creates a staging repository to hold the artifacts. If they don't pass QA or approval, you can drop the whole staging repository which ensures they cannot be used. If they do pass, the contents of the entire staging repo can be released to an approved repo. We use this feature for our internally developed artifacts. Basically, when we build a release candidate and do a maven deploy the artifacts go to a staging repo (Maven settings.xml is configured with a special Nexus URL for deploy). You can configure different filters (targets), so you can have multiple staging repositories too. The staging repos do not have third party artifacts, maven plugins, etc. However, we configured a repository group as I also referenced for these test/QA purposes. This test group repo contains our 3rd party repo, our approved external artifact repo (which would contain things like maven plugins and other artifacts available on central or other external repos), our "released" repo containing our internally developed artifacts, and then any dynamically created staging repo. We can then point an instance of Maven at this special group and have access to all of our approved artifacts as well as the release candidate artifacts. I'd recommend checking out the documentation - http://www.sonatype.com/books/nexus-book/reference/staging.html - as it explains it a lot better than I can and talks about some additional features that we don't use. You might also want to check the documentation on the repo groups for a clearer explanation than I provided - http://www.sonatype.com/books/nexus-book/reference/config-sect-managing-groups.html I would agree with the other posts though, sounds like selecting and setting up a repository manager of some kind would be useful for you. Kind of sounds like you're almost hosting your own in a way with the Apache web server/private repo combo. Nexus and Artifactory are the two products I usually see others reference, but I'm sure there are a few other products out there too. Both Nexus and Artifactory offer free versions as well as licensed versions with some additional features should you have the need for them. Artifactory has pretty good documentation too on their site if you wanted to research their features. Good luck! Dave Bruley Lead Technical Analyst CoreLink Administrative Solutions -----Original Message----- From: Sony Antony [mailto:[email protected]] Sent: Thursday, April 21, 2011 7:48 PM To: Maven Users List Subject: Re: Advantages of using a Repository Manager David : Great writeup. Many thanks. "Is that one copy per project built? Or do all builds on Hudson use that private repo" there is only one private repo for hudson, which was created only once in teh beginning of hudson setup, by copying from teh "master repository" ( We have multiple independent hudson installations building independent projects and different releases of teh same project. Each of these hudson installations get their own private repository when they are setup in the beginning - copied from teh master repository ) 1. The biggest take away from your list was teh ability to easily search for classes from the nexus interface. Agree this is something that would be very handy for us. 2. I did not quite understand your staging suite. What is in the staging repository ? Your project artifacts ? Will it include third party dependencies ? What about maven plugins ? 3. As for how developers building it. We also have what we call "taiga builds". These are complete builds outside maven. These are kicked off many times during teh day ( any developer can kick off these ). This was also setup by copying and creating a private repository in the beginning ( only once ). Whenever we do a taiga build, latest project artifacts get added to this private repository. Now, we have put an Apache web server around this private repository. All developers point to this webserver using a setting.xml which defines this web server as the only remote repository. ( I acknowledge that this arrangement has teh problem that developers might get different artifacts from different builds - if the latest build failed after building some of teh artifacts successfully ) 4. Responding to wheeler : We use install plugin to manually install some of teh third party plugins and dependency artifacts to teh master repository, that are not released through maven central. Thanks again for writing it up --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]
