commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henri Yandell" <>
Subject Re: Maven 2 (WAS: [VOTE] commons-fileupload 1.2 (rc2))
Date Mon, 05 Feb 2007 16:44:56 GMT
On 2/5/07, Jörg Schaible <> wrote:
> Hi Jochen,
> Jochen Wiedmann wrote on Monday, February 05, 2007 9:03 AM:
> >> I'm thinking:
> >>
> >> * Change group id?
> >
> > Couldn't we do that *after* the release, please? I would clearly
> > prefer *not* to introduce any incompatible changes in that stage.
> +1
> from my personal experience with a different project all I can say is that changing the
groupId is
> a task that is not very well supported by M2. The available docs are spare, do not work
as they
> are described or are out of date. So changing the groupId is a task that should be done
for a
> reference project that volunteers to go through all the hassle with a direct helping
hand from
> some Maven folks.

My understanding was that once we started doing m2 builds we would be
changing group ids. What I really mean here is deploying to an m2
repository rather than doing m2 builds. So if Jochen's plan is to do
an m2 build and send it to the m2 repository, then this point is moot.

> >> * How do we build a 2.0 release and vote on that rather than voting
> >> on the release manager's ability to do a release? Is there a way to
> >> deploy known files to an m2 repository rather than having to rebuild?
> >
> > I never intended to publish the exact distributables that we voted on.
> > For example, I never intented to change version numbers within the
> > binary distributables from 1.2rc2 to 1.2. How do others do that?
> This seems currently a process in flux. It seems clear that the standard functionality
of M 2.0.4 &
> released plugins does not match the necessary steps for Apache releases. M2 folks have
> developed and improved some plugins now that support signing and staging, but nothing
> released yet. In the mean time you either live with it or you'll process some manual

Which again is really about whether we goto an m2 repository than
anything else.

We've definitely been shifting in the last few Commons releases to
building the actual 1.2 release and then voting on it, rather than
building releases with -rc2 in the jar name etc. It's just been a
tribal change on the lists currently (Craig kicked off a thread about
it a few months ago).

> > Afar from that, I never intended to use the release manager. To be
> > honest, I never got it working.
> What's the problem here? I use it all the time (although never for an Apache release

> > I was thinking along the lines of
> >
> >     mvn -Drelease clean install site assembly:assembly deploy
> >
> > Which is (apart from the "deploy") exactly what I did to build the
> > current files.
> Please also ensure, that you build from the labeled source code in Subversion. That's
the main
> advantage for me using reelase plugin.

By labeled, do you mean the svn tag?

> > If you insist, I can omit the "deploy" and do the deployment manually.
> > (In other words, omit rebuilding the files.) That said, I spent a lot
> > of time in an automatic build exactly for *not* requiring any manual
> > interventions, because I trust my build system more than myself.
> >
> >
> >> * How much of the release code can be shared - I can see stuff in the
> >> pom.xml, can that stuff be in the parent pom?
> >
> > Yes, but my clear intention was *not* to wait for a release of
> > commons-parent again (I already did so last year for several months),
> > rather than learning from this release and then move the stuff up
> > later. (Note, that I did all changes in a branch, to allow me for
> > careful integration into either trunk or commons-parent later.)
> +1
> there's always room for improvement and we should rather use a project's POM to introduce
> parts to a build then to add all stuff immediately to the parent. If the release went
fine and the
> extension has shown to be useful, we might propagate the improvement to the parent
> *afterwards*.

Sounds fine. The m2 versioning of parents does mean that even if you
do something that is later considered the wrong direction when things
are put in -parent, it won't hurt users very much.


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

View raw message