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 19:21:12 GMT

On Feb 25, 2010, at 1:12 PM, Gilles Scokart wrote:

> On 25 February 2010 17:53, 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).
> This is indeed a valuable use case.
>> 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.
> Yes, that would be interresting.
>> Maybe an opt-in approach, explicitly adding
>> final="false" on those datatype ids *designed* for extension,  
>> would be
>> 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
> If we want to allow mutability, it seems indeed safer  to keep  
> immutability
> by default (for easier maintainability of the script).
> Note that there is an other benefits to immutability : it make it  
> easier to
> make multithread system.  The more support ant has for mutable  
> datatype, the
> more complex it will be to make it multithread (and I believe  
> that's one of
> the important evolution for the coming years).
> BTW, isn't already possible to overwrite a reference?  If I  
> remember well,
> it prints a warning but it replace the object.

My example hopefully illustrated why, while it is possible to  
completely overwrite the reference, it is less than desirable to do  
so, particularly if, as DD's description of pretty much my same  
motivations seems to imply, you may even want to have multiple  
augmentations of a given reference, e.g. when multiple components of  
your build may want to contribute additional children to a reference.


> Gilles Scokart

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

View raw message