You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Wes Wannemacher <we...@wantii.com> on 2010/03/24 16:31:12 UTC

A little about Nexus / Maven Repository Management

(changed subject so we don't dilute the vote thread, since I'll have
to point to it if/when I file a JIRA to get access to
repository.apache.org)

It's not necessarily monumental... Basically, instead of manually
pushing jars around, Nexus lets you configure a little bit in your pom
file and then you can push your artifacts to Nexus, rather than
configuring scp copying, etc.

Nexus sort of has two purposes... The primary purpose is that it acts
as sort of like an intelligent cache for maven. At my current
customer's site, I have it configured like so -

central (and other repos) <- nexus <- LAN (maven users)

As you can see, here, when maven downloads artifacts and plugins, it
passes through nexus. This allows me to set rules like "only use
artifacts and plugins that come from central." In addition, when we
create artifacts here, they are deployed to Nexus and available for
everyone else.

Nexus also has a user interface that allows you to perform some
actions on the corporate repository that may prove helpful. (For this,
I can't think of any good examples off the top of my head).

The one key feature that I am hoping to gain from this is as follows -

During the process of releasing, we perform the tagging/building/etc.
by calling into the maven-release-plugin. Once this is done, we push
some jars to a special "staging" repository. While in staging, we are
supposed to change our settings.xml so that we can test the jars
sitting in staging. After testing we vote. If the vote passes, then
someone goes out and pushes the jars around some more so that they
will end up in the central repo. This is all a very manual process and
prone to error. For example, when maven scps jars to people.a.o, you
have to remember to log in to people.a.o and `chmod g+w` the jars.
Although the steps are all documented, the longer and more complex the
process, the more likely something will go wrong.

Nexus Pro has a feature that will allow us to "stage" a release. Then,
if the vote passes, from the Nexus user interface, the staged release
can be promoted. My intention is that the build process (maybe via
maven profile) will push artifacts straight to nexus. Then, the
release process should be simplified. It isn't a drastic change or
improvement, but an improvement nonetheless.

In addition to the staging capability, if our maven build is
configured to push artifacts to nexus, I am also planning to use
apache's nexus instance as the snapshot repository. I am currently
building struts1 and struts2 in apache's hudson zone. So, what I would
do is configure the hudson build to deploy to nexus and we can point
users to the nexus install if they want to test the nightly/snapshot
builds. The existing mechanism for building nightly zips is (again)
very manual, it involves shell scripts launched by hudson, etc.

As far as nexus integration goes for struts... I figured it is only
slightly intrusive and shouldn't force a change on struts1, but the
access/integrated is granted to the project as a whole, so struts1
will be able to leverage the setup as you see fit.

-Wes

On Wed, Mar 24, 2010 at 11:06 AM, Paul Benedict <pb...@apache.org> wrote:
> Wes, can you tell me more about it? I would like to see if I can do
> the same for Struts 1 if it is not too difficult.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>



-- 
Wes Wannemacher

Head Engineer, WanTii, Inc.
Need Training? Struts, Spring, Maven, Tomcat...
Ask me for a quote!

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org