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. >> * 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. > 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. > 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*. - Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
