commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig McClanahan" <>
Subject Re: [nightly build] m2 support - a little help, pls
Date Thu, 10 Aug 2006 04:47:42 GMT
On 8/9/06, Phil Steitz <> wrote:
> 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.

Keep the faith Phil ... despite some frustrations with how Maven resolves
conflicts over requests for differing versions of the same dependency,
there's a lot of good stuff here :-).

> > 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
> proper-parent.

The Struts, Shale, and MyFaces projects have evolved some pretty intricate
multiple level build environments with Maven2 that might be worth looking at
for inspiration and ideas.  The commons world is a subset of that kind of
complexity (because it's not likely to be hierarchical to more than one
level, since each library is pretty much independent), but there's good
ideas in those POMs.

> > >
> > > 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!

This was actually one of my favorite discoveries about m2.  For Shale, I
took the philosophy that a release artifact should include:
* The binary artifacts (jar, war, or whatever)
* A directory containing all the binary dependencies
* Javadocs
* Sources
* And the pom.xml in the top level directory so that, if you have
  Maven2 installed, you can just type "mvn install" in the top level
  directory of the release, and it reconstitutes itself.

Check out "framework/shale-dist" (in the Shale repository) for how this
works for the "framework" release artifact (which accumulates a bunch of
individual jars from sub-projects ... could do something like this for an
uber-commons release pretty easily once everything was m2-ized), or how each
of the webapps under framework/shale-apps can create a self contained
release that includes all of the above stuff (similar to what you might do
for an individual commons library).



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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message