ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas Lalevée <>
Subject Re: svn commit: r1032922 - /ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/
Date Tue, 09 Nov 2010 16:15:39 GMT

Le 9 nov. 2010 à 16:27, Matt Benson a écrit :

> On Nov 9, 2010, at 9:12 AM, Dominique Devienne wrote:
>> 2010/11/9 Nicolas Lalevée <>:
>>> Note: I'll commit the unit test and doc I have wrote about this task. I don't
want to enforce anything, just share the work I have done. It is still up to debate and can
still be reverted.
>> Well, process-wise we tend to discuss things out on the ML before
>> committing, or go thru the sandbox.
> I wouldn't say that we are always RTC.  For changes with potentially large impact, I
personally have always gone ahead and opened up discussion beforehand because I didn't want
a large changeset to come as a complete surprise.  But a particular "expert level" task being
added to Ant, I don't really have much problem with.

That's what I thought, this proposed task being quite trivial and having no side effect.
Obviously for larger patch or behavior change I would come first to the ML, like I did for
the project helpers for instance.

>  I don't 100% see a use for it myself, and am pretty sure that if I did want it, it wouldn't
be for simple build composition, but for some kind of parameterized situation.  I guess I'm
+0 to this task's inclusion.
>> As Stefan, I still don't quite see
>> the use case, or more precisely why the use case you describe can't be
>> achieved some other way. --DD

It can definitively be handled without that task. With Ant 1.8.1, to bind the targets "jar"
and "source" to an extension point "dist" is to create a third target:
<target name="bind-to-dist" depends="jar,source" extensionOf="dist" />

I find it cleaner to avoid creating yet another target and implement this simple bindtargets
If there are objection, I'll remove it. Use that work around for classical build files. And
put this task in EasyAnt from which I got the idea.

>> PS: There's no enum-like type for onMissingExtensionPoint? Taking it
>> as a string allow passing anithing.
> +1 here.

onMissingExtensionPoint being since 1.8.2, it can still be improved. I'll look into making
an enum-like class.


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

View raw message