Bug 27118 - Add type overrides for import
Summary: Add type overrides for import
Status: NEW
Alias: None
Product: Ant
Classification: Unclassified
Component: Core tasks (show other bugs)
Version: 1.6.0
Hardware: Other other
: P3 enhancement (vote)
Target Milestone: ---
Assignee: Ant Notifications List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-02-20 16:38 UTC by Evan
Modified: 2008-11-24 03:58 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Evan 2004-02-20 16:38:06 UTC
When you override a target in an <import>ed project, the original target is 
accessible via [importedbuildname].[targetname].  This is not true of types 
such as filesets, patternsets, selectors...

It would be extraordinarily helpful if you could override a type's definition 
replacing it, but still have the opportunity to use the overriden type's 
definition.  For example, extend a patternset by combining the original 
definition with extra patterns.

Without this capability, you have to either:
a) require that overriders, reimplement the content of the imported types via 
copy-paste (ick)
b) explicitly code into an imported build "framework" types whose sole 
existence is to be overridden and combined with the framework's default types 
in order to avoid copy-paste reuse.  For example, in the imported file

   <selector id="someselector">...</selector>
   <selector id="someoverridableselector"><filename name="**/*"/></selector>
   <target name="sometarget">
      <copy todir="...">
         <fileset dir="...">
            <and>
               <selector refid="someselector"/>
               <selector refid="someoverridableselector"/>
            </and>
         </fileset>
      </copy>
   </target>

then in importing file, 'someoverridableselector' can be changed from including 
everything to including a subset, thus refining the set of files copied 
in 'sometarget'.  In addition to being cumbersome to implement this pattern, 
this approach is pretty inefficient since anding with the 
default 'someoverridableselector' adds cost.

An alternative might work but which is nearly as unweildy is:

   <selector id="someselector">...</selector>
   <selector id="someoverridableselector">
      <and><selector refid="someselector"/></and>
   </selector>
   <target name="sometarget">
      <copy todir="...">
         <fileset dir="...">
            <selector refid="someoverridableselector"/>
         </fileset>
      </copy>
   </target>

and having the overrider choose to do:

   <selector id="someoverridableselector">
      <and>
         <myrefiningselector/>
         <selector refid="someselector"/>
      </and>
   </selector>

But having to design this extensibility into the framework is a real pain.

Instead it would be great to be able to do:

   <selector id="someselector">ant</selector>
   <target name="sometarget">
      <copy todir="...">
         <fileset dir="...">
            <selector refid="someselector"/>
         </fileset>
      </copy>
   </target>

and override 'someselector' with:

   <selector id="someselector">
      <and>
         <myrefiningselector/>
         <selector refid="importedproject.someselector"/>
      </and>
   </selector>

Alternative ways to get what I want would be great.