There have been a few threads spawned on various ASF lists lately about
the release process at the ASF and Maven projects and other Apache
projects that use Maven being compliant.
A documentation patch for the release page at
http://www.apache.org/dev/release.html is pending, but it's close enough
that I can summarize it here. The ASF produces Open _Source_ releases.
The primary artifact that is to be released and voted upon is a source
archive that is sufficient for others to use to produce the product.
Binaries that are also released have additional requirements such as
NOTICE and LICENSE files, but these are not considered to be the primary
release -- the source archive is.
Part of the default release profile in Maven is to generate sources
jars. These sources jars contain the java packages only and not the
pom.xml or any resources or test resources actually used to build the
project. In short, they aren't really close at all to what you might
find in an svn tag for the same release. The primary use of these jars
is by IDEs for debugging purposes. The Maven Core releases do produce
source archives using the assembly plugin. Plugins, Shared, and other
smaller releases do not. This part is not in compliance with the ASF
release process and needs to be fixed before the next release.
A simple solution to this problem is to bind the assembly plugin using a
src descriptor to the pom. This will work in the short term for releases
ready to go like the archetype plugin. However, it won't be very
maintainable since we have over 60 modules (i stopped counting after
plugins and shared) that are individually released. If we bind the
plugin in the Maven pom, it would produce source archives for every
single module recursively, which is not what we want here.
To solve this, I've added a new flag to the Assembly plugin that will
tell the plugin to only run in the Execution Root folder and skip
everything else. The enforcer plugin tree is a good example of how this
will work. The plugin binding would be defined in the Maven pom and thus
inherited down to the Enforcer. The Enforcer tree looks like this:
\
+---enforcer-api
+---enforcer-rules
+---maven-enforcer-plugin
\---pom.xml
Normally I would do a release of the enforcer from the top and release
the parent, the api, rules and plugin all at once. In this case I want
the source archive to zip up the entire tree. However, I may do a
release of the plugin only. In this case I would run from the
\enforcer\maven-enforcer-plugin subfolder. In this case, I want the just
maven-enforcer-plugin source archive because that's what I'm releasing.
The new flag in the assembly plugin would allow both cases to work
without changing the poms, because the goal would skip in any project
that doesn't match where Maven was executed
(!session.getExecutionRootDir().equals(basedir))
Eventually if we get this perfected, it would be appropriate to bump up
to the Apache pom so it would just work out of the box for most
projects. Since we may have to adjust the archive contents down the
road, we should make the descriptor separate from the plugin itself.
This can be done by producing a jar that contains an Apache Source
Bundle descriptor, and adding this to the assembly plugin classpath in
the execution. This will allow us to release this independent and it
would also make it easier for projects to override the descriptor in
their projects as needed.
I'll also add a skip property specific to this execution in the release
profile to allow projects that have existing source archives to be
unaffected.
To make this happen relatively quickly, I'll take finish my patch by
adding tests, and then stage a release of the assembly plugin
2.2-beta-3.1 by applying only this patch to the existing beta-3 tag so
we can cut a release without a bunch of hand wrangling over what needs
to be fixed in beta-4.
Any concerns or objections to the above plan?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
