maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Fox <>
Subject Re: AW: Update on ASF Release requirements
Date Tue, 05 May 2009 12:03:56 GMT

Mark Struberg wrote:
> Hi Brian!
>> 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.
> I'm not sure if this solution will work. I know of a few projects using the assembly
plugin in submodules for other things than distribution.src.tar.gz creation.
This will be a separate config in a specific release profile execution, 
the flag won't affect other distributions.
> What about quickly hacking a maven-sourcedistribution-plugin.
> This plugin may safely use your trick with the parent disabling the clients, which I
find a very cool thing.
No need, it's a simple flag in the assembly plugin that won't conflict 
with anyone else.
> Maybe this could also be an additional mojo in the assembly plugin and so reuse many
of the existing functionality?
I was going to do that originally, but it's such a tiny bit of code to 
make it work for any assembly mojo, i went with the flag.
> 3rd way (and possibly the cleanest) would be to additionally to 2) add something like
a 'skipOnParentInvocation' flag to the single assembly XMLs.
> LieGrue,
> strub
> ----- Urspr√ľngliche Mail ----
>> Von: Brian Fox <>
>> An:
>> Gesendet: Dienstag, den 5. Mai 2009, 03:01:25 Uhr
>> Betreff: Update on ASF Release requirements
>> 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 
>> 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:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message