| IF task | IF task 2003-03-27 - By Dale Anson
I agree. Ant is nice in that it doesn't have a lot of cruft (not to say
there isn't any, just not a lot). Adding custom tasks is easy, adding
new tasks to the core means adding stuff that others may consider to be
cruft and that someone would have to maintain. Personally, I don't use
many of the tasks in the optional.jar, so I suppose it could be called
cruft from my usage of it.
I think that rather than continue to add tasks to the core task set, new
tasks should be packaged separately. Then users download only the task
packages that they need. I also think that some restructuring of the
main core set of tasks needs to be done, for instance, the cvs tasks
could be moved out of the core and into their own package, downloaded
only if the user actually uses cvs, instead of say perforce or vss. A
simple "plugin" sort of architecture would be fairly easy to implement,
and I believe there is work ongoing to provide this kind of
functionality to Ant.
In the mean time, adding external/custom tasks is quite easy now. Just
because a particular task is not part of the core distribution shouldn't
exclude a task from inclusion in a project if it fits the project's needs.
As for <if>, I like it and use it a lot. Even more useful is <try>. I
wrote and included these tasks in Antelope because I didn't know about
ant-contrib at that time. I have seen other implementations of both <if>
and <try> as well. My thought is that if you need a specific task for a
specific need, it's out there, so grab it and use it, or write your own!
This easy extensibility of Ant that is one of its better features.
Dale Anson
Stefan Bodewig wrote:
>On Wed, 26 Mar 2003, Antoine Levy-Lambert <levylambert@(protected)>
>wrote:
>
>
>
>>Could you explain why you think it is not likely that <if/> makes
>>its way into ant-core from ant-contrib ?
>>
>>
>
>If forced to - prepare for a long mail and probably an even longer
>thread with some unpleasant words thrown around (not by me, promised -
>it's just what usually happens when those questions don't go
>unanswered 8-).
>
>First of all, it is unlikely that we'll have any release with any new
>features within the next two or three months at all. Judging from the
>release of Ant 1.5 - our last major release with new functionality -
>it takes up to two months between the first beta and the final
>release. And I don't see us anywhere close to a 1.6beta right now.
>
>I could try to escape the more difficult part of your question with
>this. I could also try to explain why I think that Ant should not be
>abused as a scripting language, get beat for saying that and after a
>long flame-fest disclose that I'm the author of ant-contrib's <if>
>task. Which option do you prefer?
>
>OK, I'll try to answer seriously. ;-)
>
>It is a little difficult to argue for me, as I'm not really strongly
>opposed to the idea of adding them, even though I think it wouldn't be
>a good idea.
>
>The most important argument when we've discussed the "scripty" tasks
>has been that having them in Ant's core will encourage their use.
>Most of the time, people who want <if> tasks, are simply not aware of
>the other options Ant offers. They'll limit themselves.
>
>Judging from some of the mails on this list, people might end up doing
>this here
>
><foreach target="compile-it" param="file">
> <fileset dir="src" includes="**/*.java"/>
></foreach>
>
><target name="compile-it">
> <if>
> <uptodate>
> <srcfiles dir="src" includes="${file}"/>
> <mapper type="glob" from="*.java" to="dest/*.class"/>
> </uptodate>
> <else>
> <javac srcdir="src" destdir="dest" includes="${file}"/>
> </else>
> </if>
></target>
>
>OK, I may be exaggerating, but I think you get the idea.
>
>I realize that there are use-cases for <if> and <foreach> and maybe
>even <switch>, but they are less common than generally claimed IMHO.
>As I said, I'm the author of ant-contrib's <if> and apart from the
>unit tests in ant-contrib, I've never written a build file that uses
>it.
>
>Let's make a list of pros and cons:
>
>pro <if> (and friends?) inside Ant's distribution:
>
>* easy to use the tasks
>
>well, you avoid a single <taskdef> and a download.
>
>con <if> (and friends?) inside Ant's distribution:
>
>* adds more tasks to Ant
>
>* couples <if>'s release cycle to that of Ant, while it may see more
> frequent releases outside of Ant
>
>* may be used as what seems to be an easy solution to create
> unnecessarily complicated build files
>
>
>
>><IMHO> I feel that these features are desired by a lot of the users
>>of ant, maybe by the majority. </IMHO>
>>
>>
>
>If thought a long time on whether I should simply ignore this, add
>fuel for another flame-war by deriving a political statement from this
>by replacing "these features" and "users of ant" with different terms,
>talk about the difference between meritocracy and democracy or ...
>
>Let's say that the Ant committers have been standing against pressure
>to add certain things for a long time. Doing so has not done any harm
>to Ant, quite the opposite IMHO as it has kept Ant as clean as it is
>(which may not be that much). We've had a time where adding support
>for JavaScript evaluated expressions inside target's if attribute
>seemed to be desired by a lot of users.
>
>At the same time, I firmly believe that Ant committers are not
>ignoring their user base.
>
>People who really feel a strong need for <if> know where to find it.
>Adding a single <taskdef> isn't hard to do.
>
>Stefan
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: user-unsubscribe@(protected)
>For additional commands, e-mail: user-help@(protected)
>
>
>
|
|
 |
