You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Sony Antony <so...@gmail.com> on 2011/04/20 14:23:48 UTC
Advantages of using a Repository Manager
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
Re: Advantages of using a Repository Manager
Posted by Brian Smith <bm...@gmail.com>.
Hi there,
We have a slightly more open setup than you do where developers can add
libraries _provided_ they're licensed under pre-approved business friendly
licenses.
Artifactory works excellently for us in that respect as it allows us to
handle permissions at the right level, I also personally find the UI to be
very intuitive and simple.
We also use the repository to publish API libraries to our internal
solutions teams and as an archive of customer deliverables quickly
accessible by support.
Repository Managers in general are very useful and Artifactory (power pack)
in particular would get a recommendation from me.
Kind regards
Brian
On 20 April 2011 13:23, Sony Antony <so...@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
>
RE: Advantages of using a Repository Manager
Posted by David Bruley <Da...@corelinksolutions.com>.
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:sony.antony@gmail.com]
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Advantages of using a Repository Manager
Posted by Sony Antony <so...@gmail.com>.
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.Bruley@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.antony@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 <so...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Advantages of using a Repository Manager
Posted by Ron Wheeler <rw...@artifact-software.com>.
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.antony@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<so...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Advantages of using a Repository Manager
Posted by David Bruley <Da...@corelinksolutions.com>.
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.antony@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 <so...@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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Advantages of using a Repository Manager
Posted by Sony Antony <so...@gmail.com>.
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 <so...@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
> >
>
Re: Advantages of using a Repository Manager
Posted by 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 <so...@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
>