ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antoine Levy Lambert <>
Subject Re: task that allows augmentation of previously declared references
Date Thu, 25 Feb 2010 19:55:44 GMT
Matt Benson wrote:
> On Feb 25, 2010, at 10:53 AM, Dominique Devienne wrote:
>> On Thu, Feb 25, 2010 at 10:00 AM, Gilles Scokart <> 
>> wrote:
>>> Did you have any example to demonstrates the benefits of such task ?
>> The benefits with conjunction with <import> could be important, in
>> that you can "mix-in" specialized pre-defined builds dealing with
>> specific concerns (like JAXB pre-compilation for example) and have
>> those builds "implicitly" augment the classpath or Javac source path
>> appropriately for example (as documented in those builds, and you do
>> explicitly import those, so are kinda in control). Sure, it does open
>> the door for some complexity, and Ant would enter some un-chartered
>> waters indeed, but when trying to design reusable builds in the
>> (distant now) past, I've often felt the need for such a feature. Yet
>> it doesn't necessarily mean that would have been the right solution
>> either. I'd be interesting to have the input of the EasyAnt people on
>> the matter in fact. Maybe an opt-in approach, explicitly adding
>> final="false" on those datatype ids *designed* for extension, would be
> I could live with this.  :)  We could also include a magic property 
> for the default.  
I do not like very much magic properties. I think we would be fine if by 
default all datatypes instances can be augmented. In fact they can 
already by special tasks or scripting. Adding a new attribute final on 
datatypes allowing users to write

<fileset id="myunmodifiablefileset" final="true" dir="foo/bar">
   <include name="special.txt"/>

would be fine.


> Having the augmentation feature supported at such a low level would 
> help establish its specialness, which is most evident in its (ab)use 
> of the id attribute, which decision I must stand by, however, since 
> this is the only attribute we should be guaranteed not to need to 
> modify on the original referenced object.
> -Matt
>> a more conservative introduction of this feature, although that does
>> force to have "perfect hindsight" into what will be necessary to
>> extend/augment or not. --DD

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message