ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <>
Subject Re: task that allows augmentation of previously declared references
Date Thu, 25 Feb 2010 21:01:15 GMT

On Feb 25, 2010, at 1:55 PM, Antoine Levy Lambert wrote:

> 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"/>
>   </fileset>
> would be fine.

In the vein of discussing whether we have some notion of declaring  
that a given reference cannot be augmented, and thus granting some  
degree of "specialness" to this task, I also note a test failure that  
I didn't originally understand was mine with my local change to  
RuntimeConfigurable.  If AugmentReference is special, then  
RuntimeConfigurable can explicitly know about it and the broken test  
situation goes away.  :)


> Regards,
> Antoine
>> 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:

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

View raw message