commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Lundberg <>
Subject Re: Maven 2 (WAS: [VOTE] commons-fileupload 1.2 (rc2))
Date Mon, 05 Feb 2007 20:39:52 GMT
Henri Yandell wrote:
> 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.

I put together this document when I was trying to pull through the whole 
groupId change last time:

There is never a good time to change the groupId. My view is that we 
should do it when we move to M2, both as a build tool and as the target 

> 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 is
>> released yet. In the mean time you either live with it or you'll 
>> process some manual steps.

Releases have been made, but not yet for all the plugins that take part 
in the release process. It is very close though.

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


> Hen

Dennis Lundberg

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

View raw message