commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz" <phil.ste...@gmail.com>
Subject Re: [nightly build] m2 support - a little help, pls
Date Thu, 10 Aug 2006 06:13:22 GMT
On 8/9/06, Craig McClanahan <craigmcc@apache.org> wrote:
> On 8/9/06, Phil Steitz <phil.steitz@gmail.com> wrote:
> >
> > On 8/9/06, Brett Porter <brett@apache.org> 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 :-).
>
Yes indeed.  Just need to learn it and get some docs out so we can all
take advantage of it.

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

Thanks!  Will definitely have a look.
>
<snip/>
>
> 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

You mean bundling all of the dependent jars?  Doesn' t that sort of
defeat the purpose of the maven repo setup?

> * 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.
>
Do you think we should do away with the source vs binary distinction?
Looks like you are pretty much including everything there.

> 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).

Interesting.  Definitely more complex than what we have in commons,
but lots of good examples.  We collectively need to get itches and
cycles to get this experience into /dev docs for apache projects and
to help improve the maven docs in general.

Thanks!

Phil
>
>
> Phil
>
>
> Craig
>
>
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
>
>

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


Mime
View raw message