Bug 46087

Summary: Aggregating filesets is *functionally* possible and would be very useful for large projects
Product: Ant Reporter: Aleksandar Susnjar <asusnjar>
Component: CoreAssignee: Ant Notifications List <notifications>
Status: NEEDINFO ---    
Severity: enhancement    
Priority: P2    
Version: 1.7.1   
Target Milestone: ---   
Hardware: All   
OS: All   

Description Aleksandar Susnjar 2008-10-25 06:46:52 UTC 
Currently there is no way to aggregate multiple filesets. I attempted to make a custom aggregating fileset and came close - what stopped me is not the filesets themselves but they way they are used (or actually bypassed). Resource objects it returns are not "asked" to provide access to resources but only their location, which is then opened/created/accessed by the task using a fileset - for example, a zip task appears to differentiate 'zip' and 'ordinary' resources instead of having this functionality encapsulated within the resource itself.

What would be the functional meaning of this? Well, take any task that can take multiple filesets. Zip, for example. These filesets can have different base directories and can include/match different resources within them. Their base directories are not important at all in many (most or all?) such cases. Currently aggregation of filesets has to be deferred until they are referenced by such tasks, which may be too late. Consider a very large projects with many semi-independent components that need to make it into the same archive, say *.ear file. Each one of these components knows what should go in there, but the "bundling" build script and associated task do not - they are supposed to delegate this responsibility to those components. So current options in that example are:

1. Have a single ear task that must know about all filesets of all components. If a component changes (and adds a new fileset), that bundling task must also change.

2. Build ear in stages, letting each component update it (enrich it) with its own stuff. This is very slow.

Perhaps there is more, but you can appreciate how useful it would be if each component could define a single aggregate fileset of all of its stuff and publish that single one. Any changes to it would be localized to that component, and the external bundle script would not have to 'care'.
Comment 1 Aleksandar Susnjar 2008-10-25 07:06:30 UTC 
One more thing: why is this important? From my perspective, one differentiating factor between ant and other build software is that it can do what other, perhaps simpler-to-use, software cannot do. This leaves ant with the more complex scenarios, rather than the simple one. And in these complex scenarios, features that can enhance build script structure, maintenance and flexibility becomes very important.
Comment 2 Stefan Bodewig 2009-07-31 07:44:03 UTC 
doesn't a <union>-ResourceCollection do the trick?
Comment 3 Ewan Chalmers 2011-12-15 13:55:55 UTC 
Union does not seem to work for archive filesets. If I attempt to create a union of zipfilesets (so that I can reuse it to create a zip and a tar), the non-basic-fileset attributes appear to get lost in the union. For example, zipfileset.prefix is not used in the archive that gets created.
Comment 4 Matt Benson 2011-12-16 20:03:32 UTC 
(In reply to comment #3)
> Union does not seem to work for archive filesets. If I attempt to create a
> union of zipfilesets (so that I can reuse it to create a zip and a tar), the
> non-basic-fileset attributes appear to get lost in the union. For example,
> zipfileset.prefix is not used in the archive that gets created.

Hmm, that shouldn't be the case.  Any chance the <archives> collection works any better for you?  A sample buildfile, particularly one presented in antunit form, would be very helpful.