Hi, See also [1]. This is the documented process we use over in Felix: It is based on a build profile (release) in the parent pom [2] (which is different from the root/reactor pom, which is important and simplifies matters).
This profile has two setups: * generate the signatures * build the source and binary artifacts I think, this catches just about everything and enables automation by allowing to perform a release build with just two commands : mvn release:prepare and mvn release:perform. Now, part of a release build process is tagging the project and raising version numbers. I think it is very valuable that the release plugin also automates this step (except for the pom.xml license header removal if the <project> tag is not on a single line) as it is certainly error prone and worth automation. Regards Felix [1] http://felix.apache.org/site/release-management.html [2] http://svn.apache.org/repos/asf/felix/trunk/pom/pom.xml Am Mittwoch, den 26.03.2008, 22:53 +0200 schrieb Jukka Zitting: > Hi, > > On Wed, Mar 26, 2008 at 10:01 PM, Felix Meschberger <[EMAIL PROTECTED]> wrote: > > Am Mittwoch, den 26.03.2008, 16:29 +0200 schrieb Jukka Zitting: > > > One of the reasons why I prefer not to use the maven-release-plugin. > > > Not terribly bad IMHO, but not ideal either. > > > > Hmm, this is a known issue with the maven-release-plugin: the <project> > > tag must be on a single line, otherwise this happens... > > ACK. I think we can live with this. > > > On the other hand, if this is the sole issue with the > > maven-release-plugin, so what ? There is a known workaround. On the > > other hand the plugin takes a lot of manual work off our shoulders and > > therefore is worth considering. > > Perhaps it's just my prejudice, but one concern with > maven-release-plugin is that it takes over the SCM interaction and > commits stuff directly to svn. I'm much more fond of tools like > svnmerge.py that just prepare a set of changes in the local copy and > let the user review and explicitly commit those changes. Of course you > can revert things in svn if the tool does something wrong, so perhaps > I'm just being overly paranoid. > > Another issue is that maven-release-plugin only really cares about > Maven, whereas our release process should primarily be producing the > -src.jar package that simply contains the exact release sources as > tagged in svn. We could let maven-release-plugin do the release work > and then create the -src.jar from the produced tag, but that seems a > bit backwards and requires extra work. The maven-release-plugin also > doesn't support the concept of a release vote. > > So, while I'm all for increasing release automation, I'm not yet > convinced that maven-release-plugin is the tool we should be using. > But feel free to convince me otherwise. :-) > > BR, > > Jukka Zitting
