> From: Mike Jennings [mailto:[EMAIL PROTECTED]
>
> > Ok here is the argument about being not such a good idea
> (in general).
> > 1) For every contition you need to test in the whole of
> your buildfile
> > you need to come up with yet another property that will be use for
> > testing it.
> >
> > 2) Then you need to make sure that all your properties have been
> > tested,
> >
> > and those that are not defined because of the test, will never be
> > defined later by some other part of your build.
> >
> > In escence, it is noce for small things, but for large builds it
> > becomes a real nightmare.
> >
> > What other competing stuff is out there:
> >
> > a) Use <if> from antcontrib (more to the point: convice enough
> > comitters to get <if> and such inside core, since some
> people do not
> > like importing 3rd parties
> > for such basic functionality. The people against claim is
> too verbose.
> >
> > b) Some have proposed the idea of an evaluation language
> that can be
> > used inside the if/unless attributes. That would allow expressing
> > conplex conditions
> > without needing to define properties for each one of them.
> Also means a
> > language must be defined or adopted and it must have enough
> expressing
> > power.
>
> > All this things do not exclude one another, but before we embark on
> > some direction we need to think about what will be best for
> > readability, maintenability, etc.
> >
> > Jose Alberto
>
> Thanks for the explanation Jose! I understand the problem
> with coming up unique property names just to use in an if= or
> unless=. Why not use 2 approaches? In my opinion
>
> <target name="debugstuff" if="debugmode">
> ...
> </target>
>
> is quite readable and I would not want to give that up. But
> using just the existence/nonexistence of a property is useful
> only in particular instances. Trying to use that approach for
> all conditional behaviour is a bad idea. Having the <if> task
> as a core task seems an obvious and good idea to me. That
> being said, being able to embed
>
> <echo if="debugmode">
> You are compiling in debug mode
> </echo>
>
> in the middle of a target (without having to make multiple
> targets) would be pretty cool also.
>
I do not disagree, in principle with you. However, if we only offer
if/unless as the feature in CORE, people (because many are not aware
of antcontrib) will think that that is the only way and will produce
hard to
maintain buildfiles (which will detract on the appeal of ANT in the
future,
I can hear MS-build using such an argument).
I think in 1.7, we need to look more at ANT "the process flow scripting
language"
which is what many people are starting to use it for, if you really
think about it.
It is not just "build my library", it is "run my testcases", "install my
release",
etc. So, the need for conditional actions goes beyond "debugmode" and we
should
just try to encompass these things in an structured maner.
This is why I am all for <if/> and such in CORE, and the reason why some
people
are against it (ANT is not for scripting, argument).
As per if/unless itself, I really would like to explore more what some
people
have suggested about having a richer language than just set/unset. Some
people proposed a real expression evaluation language so we do not need
to polute with makeup properties for ovbious things. I would like to
explore that
and see if we can design it in such a way that:
1) Is backward compatible (i.e., if="propertyname" means property is
set)
2) Allows usage of the current condition infrastructure (i.e. we do not
need to write
another version of <available/> and so on (e.g., if="available(${file})"
).
3) Your 3rd party conditions from antlibs are first class citizens.
4) The syntax is nice. Maybe we can use something already out there.
Sounds like a big agenda ....
Jose Alberto
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
