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