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