Great note. Thanks for taking the time to put this together. It has some
great ideas that even experienced Nexus users will find helpful.
We are not nearly this sophisticated but we found that the free version
of Nexus (competitors might do just as well) made our use and
understanding of Maven much more trouble-free since it added a lot of
transparency to dependency management.
The support for 3rd party libraries that are not released through Maven
Central is very useful.
We are just using the free version since we have a very small team
although we have lots of POMs - about 90 in our largest project.
I would strongly recommend getting a repo into any development
environment that includes Maven.
Ron
On 21/04/2011 10:48 AM, David Bruley 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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
