Jose Alberto, Diane and others,
it's not so much about what *I* want - well I realize in some way it
is - but more about what Ant should be.
IMHO we shouldn't try to make Ant the solution for everything. Ant
should be small and easy - and maybe we've already left this ground,
I'm not sure.
Unlike Peter I can't remember the heated discussion about the if
attributes on targets because I haven't been there at this time - but
I do remember the reaction when I first proposed enhanced
conditionals (yes I did). Now I realize that rejecting my proposal was
the right thing.
The main reason why people need enhanced conditionals is that they are
converting old Makefiles or are used to make and think in terms of how
they would do what they need in make.
My example was converting a (open source) JDBC driver project from a
Makefile to Ant (because the Makefile was/is a mess when taking
JDBC-1/2 jikes/javac Windows/Unix into account).
In this Makefile the user would need to change a variable JDBC_VER to
1_0 or 2_0 depending on what he wanted to compile - the all target
would include ResultSet_$(JDBC_VER).class then.
How was I going to do this in Ant? I could include
**/*${JDBC_VER}.java but how should I exclude the files for the other
version? Having the user specify another NOT_JDBC_VER property is
silly, so I decided I needed a way to set one property based on the
value of another one. Wrong!
What I do now is check whether it is JDK 1.2+ I'm running on
(available) and exclude 1_0 if jdk1.2+ and 2_0 unless jdk1.2+. Much
cleaner and the user doesn't even need to specify the JDBC version.
Back to this thread
>>>>> "JAF" == Jose Alberto Fernandez <[EMAIL PROTECTED]> writes:
JAF> Well, Stefan, I actually wrote <case> following your comments
JAF> about my modifications to the "if" attribute. You proposed that
JAF> this kind of thing should be better in a task.
Yes I did, but I think we'd be giving the wrong signals if we included
anything that looks like control structures into the Ant distribution
(even as an optional task, sorry). Once we have the extension
mechanism up and running, I might get convinced that having a
control.tsk jar file with <case>, <if>, <foreach> wouldn't hurt too
much.
Please understand that this is not just rejecting it "because I can".
>>>>> "DH" == Diane Holt <[EMAIL PROTECTED]> writes:
DH> My ant wrapper-script is already far larger and more complicated
DH> than I originally thought it would ever need to be. And if I
DH> needed this all to work under something other than a Unix-type
DH> shell, I'd have to have duplicate scripts that talked that
DH> shell's language -- which could turn into a maintenance
DH> nightmare, and which severely detracts from the "platform
DH> independence" that Ant is supposed to provide.
This is a big problem and of course this is not what Ant is supposed
to do. I wouldn't advise anybody to put the logic into a wrapper
_script_, this is why I think a Java front end to Ant is required, but
let's make them two separate beasts (from the development point of
view, not necessary for the user).
DH> I'm sorry, but I just don't get it. Personally, I think this
DH> alarmist attitude towards a test-for-value capability is just
DH> silly.
Call it paranoia if you want - but if I had the choice between moving
Ant even slightly into the direction of make (causing a maintenance
nightmare) or making Ant unusable in certain situations I'd chose the
latter.
Stefan
