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 On Thu, Apr 21, 2011 at 10:48 AM, David Bruley < dave.bru...@corelinksolutions.com> wrote: > 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:sony.ant...@gmail.com] > 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 <ta...@cservenak.net> > > > 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 <sony.ant...@gmail.com> > > 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: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
