ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@gmail.com>
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  
>>> <gscokart@gmail.com> 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.  :)

-Matt

> 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: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message