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 Mon, 22 Mar 2010 13:50:03 GMT

On Mar 22, 2010, at 5:42 AM, Jean-Louis Boudart wrote:

> Sorry for the delay.
> I really like the idea of being able to "augment" previously declared
> reference. There is many uses cases where it can be useful.
> For example, if ant can provides such feature it would simplify a  
> lot the
> job in easyant for projects using many directories as source folder.
> They will just need to augment the fileset used for source folder.
> It makes also senses for other dataType.
> I'm also +1 for the "final=false" attribute.
> By the way i think the only use case that is discutable is for  
> <path>. Most
> of the time we want to append something to an existing classpath,  
> so here
> augment make sense. But how will the augment feature will help us  
> if we want
> to prepend things in the classpath (for example if we use coverage  
> tools,
> instrumented classes must be put before the compiled classes in the
> classpath)?
> In EasyAnt we've defined our own <path> task that handle this use  
> cases
> (allowing prepend / append / overwrite).
> Considering that this problem cannot be solved just by using "augment"
> feature, should we improve the behavior of <path> task? or let each  
> projects
> defined their own task to do this?
> Is the augment feature already commited on trunk (i've not checked  
> the trunk
> for a while)? Is it targeted to be in the 1.8.1?

It depends on the timeframe for 1.8.1.  I haven't been able to  
clearly gauge the general direction of majority opinion on the  
"final" issue.


> My 2 cents
> 2010/2/25 Dominique Devienne <>
>> 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
>> 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:
> -- 
> Jean Louis Boudart
> Independent consultant
> Project Lead

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

View raw message