Brian Fox wrote:
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.
Hi Brian,
I just created issue MASSEMBLY-409 which describes two other problems we encountered by using the "project" assembly for our recent Apache
Portals releases.
It would be great if you can take that issue and the recommended
fixes/solutions into consideration for the next release too:
http://jira.codehaus.org/browse/MASSEMBLY-409
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?)
Why drop .bz2 in the first place?
We have been using .bz2, .tar.gz and .zip based distro releases always and
AFAIK most other ASF projects too.
With this change, we'll be forced to build the missing ones manually ourselves and/or won't be able to use *only* the new "project" assembly
within our release procedures.
But, as I indicated in MASSEMBLY-409 (see above), if predefined assemblies can be modified to accept additional configuration
settings/overrides, *then* this would not be a problem as we can configure the needed formats ourselves then.
Also, I used source-release as the id which would produce bundles like
foo-1.0-source-release.zip. Any strong feelings on this?
That is a "workaround" for the second issue I described in MASSEMBLY-409, but I'd still prefer being able to configure the "classifier"
ourselves. We have been using -src as "standard" extension to indicate a source distribution for all our previous releases, just as most
other ASF projects AFAIK, and very much prefer being able to continue to do so.
Regards,
Ate
[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?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
