commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz" <>
Subject Re: [nightly build] m2 support - a little help, pls
Date Thu, 10 Aug 2006 04:34:19 GMT
On 8/9/06, Brett Porter <> wrote:
> On 10/08/2006 1:21 PM, Phil Steitz wrote:
> > I would like to add m2 support to the nightly build script, but am
> > still an m2 newbie, so could use a little help.  I thought that
> > starting with [csv] would be good, since the migration page lists it
> > as "done".   I have a couple of questions.
> >
> > 1. It seems to use pom inheritence, which I am sure someone will
> > convince me is a good thing, despite the fact that my first experience
> > with it is a build failure because of it.  How do I find and I guess
> > "install" the commons-sandbox-parent?
> It's in sandbox-trunks for now

OK, so I just did "mvn install" from the root of sandbox trunk and I
guess that did it.

> How do we indicate to users
> > that they are going to need to set this up for builds to work?
> It shouldn't be necessary. If the parent is finalised and released as an
> independant artifact first, it will be downloaded from the repository
> like any dependency.
> Do we
> > really need this?
> It's extremely useful for reducing duplication and making changes (such
> as repository location) easier, and also allows the same for any
> generated sites, so I'd say yes :)

OK, so the repo list will eventually go there?  When it failed once it
displayed a list of repos including apache.snapshots that I could not
figure out where it was getting.  I guess those are defaults and the
right way to set things up is to use repository elements in the pom.
So these should probably be specified then in the sandbox-parent and
> >
> > 2. Properties files seem to be replaced by settings.xml.  Is this
> > where we designate repo lists?  If so, can someone commit a
> > settings.xml.sample?
> is replaced by pom.xml (ie, plugin configuration is
> brought in). This is all you should need to commit to SVN, and it can
> contain repository references if needed.
> settings.xml is the equivalent of ~/ It should only
> need additions if you are a deployer or want to add additional
> repositories yourself.
Good.  We should then provide examples for RMs eventually.
> >
> > 3. I assume that the reference to 'minotaur' in the
> > distributionManagement section of the csv pom should be changed to
> > 'people'?  Once this is fixed, I assume "deploy" will work correctly
> > using the ssh key that the script is using to connect to people now.
> Should do.
> >
> > 4. The dist plugin seems to be gone and the release plugin looks like
> > it is really just aiming to deploy jars and tag releases.  Should I
> > use ant tasks to roll the distros manually or is there some m2 plugin
> > that will do this?
> The assembly plugin is the equivalent of dist (but is a lot more
> flexible). There is a default descriptor for building source and binary
> tarballs/zips, but you can also create your own, describing the layout
> of the resulting archive.

Nice!  Much nicer than the old muck with maven.xml approach. I will
have a play with this and either use built-ins or commit descriptors
that we can use for the nightlies to start and then standardize for
releases. Suggestions / commits welcome!


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message