We're fixing the directoryscanner to allow regular expressions in addition to the ant syntax. Then we can do (?!.*/src/.*).*/target/.*
On Mon, May 25, 2009 at 6:58 PM, Brett Porter <br...@apache.org> wrote: > How about an option <excludeBuildDirectories>true</excludeBuildDirectories> > that uses the list of build directories from all projects in the reactor an > applies that to the fileset excludes? > > It could be either descriptor-wide, or per-fileset I guess. > > Short of that, I'd say to get it off the ground to tell projects they need > to alter the descriptor when using it to explicitly include their non-build > target directories. > > - Brett > > > On 21/05/2009, at 7:14 AM, Brian Fox wrote: > > 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 >>> >>> >>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
