Introducing the configurability in the descriptor itself requires more changes to the assembly code than I think we should tackle right now. I also think we should strive to build a descriptor that works for all projects to the extent possible. That said, I'll make a property in the plugin config to make it easier for projects to disable this execution and/or use a different descriptor of their choosing. Now, I solved the MASSEMBLY-405 issue, but this causes a few more problems we need to look into. It causes us to need something like **\target\** to exclude the build artifacts from the assembly, but several projects in maven use target folders in their test resources (archetype, install, deploy). The solution to this yet is still undefined.
On Mon, May 18, 2009 at 11:36 AM, Ate Douma <a...@douma.nu> wrote: > Brian Fox wrote: > >> On Mon, May 18, 2009 at 8:57 AM, Ate Douma <a...@douma.nu> wrote: >> >> 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 >>> >>> >> I don't see those as being problems with the approach I'm taking. The asf >> descriptor will be separate from the plugin so we can tweak it as needed, >> and projects can introduce their own descriptors instead of the default if >> they want. >> > Well, yes. But with the current restrictions (no configuration overrides) > it might result in a lot (most) ASF projects needing to provide their own > which makes the whole point of this "project" descriptor a bit useless IMO. > > >> >> >>> >>> 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? >>> >> >> >> The source archives for everything are going to significantly increase the >> bandwidth to mirror and disk to store millions of artifacts. We should be >> conservative and use the minimum, which imo is zip and bz2. >> >> 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. >>> >>> >> I'll talk with John to see what might be possible to introduce wrt >> configurability for the asf descriptor. >> > If you can enable that, all issues I described in MSASSEMBLY-409 would be > "solvable" automatically too :) > > > >> >>> 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 >>> >>> >>> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
