ant-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 46087] New: Aggregating filesets is *functionally* possible and would be very useful for large projects
Date Sat, 25 Oct 2008 13:46:54 GMT
https://issues.apache.org/bugzilla/show_bug.cgi?id=46087

           Summary: Aggregating filesets is *functionally* possible and
                    would be very useful for large projects
           Product: Ant
           Version: 1.7.1
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: Core
        AssignedTo: notifications@ant.apache.org
        ReportedBy: asusnjar@hotmail.com


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'.


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

Mime
View raw message