It's been a little slow going, but here's an update of where I'm at:
I branched assembly 2.2-beta-4-SNAPSHOT[1] from the 2.2-beta-3 tag and
renamed the trunk to 2.2-beta-5. The runOnlyOnExecutionRoot flag has been
added to 2.2-beta-4 (MASSEMBLY-406). I created a custom descriptor bundle[2]
to be used for the asf source releases. Initially this is a copy of the
default project.xml with the bz2 removed. Having it separate will give us
more flexibility to make updates w/o having to re-release the plugin.
The configuration for making a bundle with this setup currently looks like
this:
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<version>2.2-beta-4-SNAPSHOT</version>
<executions>
<execution>
<goals>
<goal>single</goal>
</goals>
<phase>validate</phase>
<configuration>
<runOnlyAtExecutionRoot>true</runOnlyAtExecutionRoot>
<descriptorRefs>
<descriptorRef>
source-release
</descriptorRef>
</descriptorRefs>
</configuration>
</execution>
</executions>
<dependencies>
<dependency>
<groupId>org.apache</groupId>
<artifactId>apache-source-release-assembly-descriptor</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
</dependencies>
</plugin>
Once I test and work out any kinks, this will be added to the maven pom and
released.
There is one bug that David Jenks found in the beta-3 code that needs to be
addressed since it affects the bundle content (MASSEMBLY-405). I hope to
have the bug fixed and assembly staged by tuesday, followed by the
descriptor bundle and then the maven/shared/plugin/etc parents later this
week.
The current descriptor produces tar.gz and zip, does anyone have strong
feelings if this is ok or should we go with only one of them? (and which
one?) Also, I used source-release as the id which would produce bundles like
foo-1.0-source-release.zip. Any strong feelings on this?
[1]
https://svn.apache.org/repos/asf/maven/plugins/branches/maven-assembly-plugin-2.2-beta-4
[2]
https://svn.apache.org/repos/asf/maven/resources/trunk/apache-source-release-assembly-descriptor
On Mon, May 4, 2009 at 9:01 PM, Brian Fox <bri...@infinity.nu> wrote:
> 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?
>
>
