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. 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. Maybe this could also be an additional mojo in the assembly plugin and so reuse many of the existing functionality? 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 <bri...@infinity.nu> > An: dev@maven.apache.org > 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 > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
