> From: Dominique Devienne [mailto:[EMAIL PROTECTED]
>
> > From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED]
> >
> > -100 :-\
> >
> > IMHO, if/unless in targets are one of the worst features we have in
> > the ANT language.
>
> I'm completely at the other end of the spectrum! I think
> if/unless, and extension of these that I coded up in my
> custom tasks/types, make the build a lot easier to read, and
> are absolutely essential to Java development with a lot of
> native code underneath like here.
>
Keyword here: "and extensions of it that I coded up in my custom
tasks/types".
Looking at your build, it seems that you agree with me that the CURRENT
if/unless is conversome. You wrote your own replacement to satisfy your
own needs.
The generic problem, is that to be able to provide a proper solution
in the spirit of if/unless the attribute should have to be able to
evaluate a possible complex expression about its environment:
property set? property true/false? file available? AND, OR, NOT, etc,
etc.
But we already have all this in our ANT conditions. So why do we want to
redefine them again with a new syntax? How do you add new conditions?
Because the need for new conditions to check does not end today.
> It all comes down again to some pundits who do not like
> features like if/unless on all tasks and want to save the
> rest of the Ant community from themselves by preventing them
> to use this idiom, which I prefer 100 times better than <if/>
> (to use the same hyperbole you used Jose Alberto ;-)
>
Well, I have use it, and I do not like it because for every value
property
to check I needed to define (or not define) another property to
to test for its existance. It becomes a problem the more complex your
build is.
> To prove my point (or show the world how bad my builds are, I
> don't know), I quickly compiled a bunch of snippets from my
> build scripts that show extensive use of if/unless or more
> precisely ifTrue/unlessTrue/os/osFamily, which are just
> extended conditions of the same sort (I could never quite
> accept the if/unless way of testing just property existence
> rather than value!).
>
> I know very well of <ac:if>, <ac:switch>, etc... and even
> used them for a time, but using inline attribute conditions
> is tons better IMHO.
>
Why? You need to define a different target for each test, and
you need to make sure that there is another target that evaluated
the condition before your target gets a chance to execute.
I always feel like writing spaggetti code, maybe if it is very well
structure it does not look that bad, but it seems to me it
tends to produce difficult to maintain buildfiles.
The main gripe I seem to feel about <if/> if that for simple usages
(test a property) the syntax is quite verbose. Well, maybe we can do
something about it. For example (some random ideas):
<ifthen property="xyz" [ value="AAA" ] >
<dothis/>
<dothat/>
</ifthen>
which would provide simple existance or value checking. With little
overhead.
My basic point is to accept some of this constructs into ANT-CORE and
evaluate any improvements that will made them more easy to use for all.
> So to make a long story short, since I doubt we'll get to any
> sort of consensus on this issue, I would propose that Ant
> implements a hook at the task or better yet execution engine
> (that turns UE into instantiated types) so that some build
> writers like me can provide custom implementation of that
> hook to add conditional aspects throughout Ant (basically custom OAP).
>
> Since Ant 1.6+ is now fully dynamic, one can envision that
> the Ant runtime would examine all UE's attributes and
> interrogate a hook, if any, passing the UE's attributes to
> it, to find out if this particular UE, be it a task, a type,
> or a nested elements of either, is to be passed to it's
> parent (if a nested element) or instantiated (if a
> task/type). If the hook says no, then it's as if that XML tag
> never existed in the build file!
>
Well, something similar is what I pointed out at the end of
my message. Although I was defining an specific semantic,
not a generic hook.
> If this was possible, Ant would remain as-is to you, but I
> could implement that hook to make globally available what I
> currently have to sprinkle everywhere in my own code, and in
> wrappers of Ant tasks when I need it for Ant tasks. You use
> <ac:if> if that suits you, and I (and quite a few others
> since if/unless on everything has been requested and even
> submitted by a few people already) can use inline condition
> attributes.
>
But notice that this hook or aspect is not the same as the if/unless
we have today. For example you cannot use it on a target.
If you were to use it, the target will disappear when the condition
is not met "the target never existed" hence it cannot be mentioned
in a dependency list since that is an error. So things are more
subtle than that.
Simillarly, the current "if" in fileset/exclude does not make things
invisible,
it is the fileset task that decides what to do about it (ignore it).
So this differences will have concequences on what one can or cannot do.
> I'm not trying to attack anyone here, although I'm sure my
> post is controversial at best, but this if/unless issue has
> been lingering long enough it seems to me, and if the Ant
> committers persists in refusing it, please at least provide
> me a framework so I can myself get a rope to hang myself with.
>
> I am also an experienced Ant user working on big builds Jose
> Alberto, and yet we still cannot be farther apart on this
> issue. I guess diversity is what makes life interesting ;-)
> But let's break the current dead-lock and move on. --DD
>
Like with every "controvertial" feature on a language, the issue
is not whether the experienced ANT user will hang him/herself, but
how many hangged junior users died due to the construct.
Or in other words, how much higher the maintenance cost goes,
due to a junior person misusing the feature.
I think the current if/unless tends to cause problems (maybe I am
not as proficient ANT writer). The question is, six month from now
can someone else get the build file and understand what is going on.
Jose Alberto
>
> <bm:echoproperty name="jar.classpath" ifTrue="${verbose}" />
>
> <echo ifTrue="${verbose}"
> xmlns="antlib:com.lgc.buildmagic">
> <path refid="modulepath" />
> <path refid="classpath" />
> <path refid="systempath" />
> <text>Building ${ant.project.name}</text>
> </echo>
>
> <buildpath id="buildpath"
> xmlns="antlib:com.lgc.buildmagic">
> <element location="Plugin" ifTrue="${plugin}" />
> <element location="Core" />
> </buildpath>
>
> <macrodef name="compile">
> <attribute name="jaxb" default="false" />
> <attribute name="register" default="false" />
>
> <sequential>
> <!-- Compile the XML schemas into Java code, if any -->
> <mkdir dir="build/generated/@{name}" />
> <bm:jaxb destDir="build/generated/@{name}" ifTrue="@{jaxb}"
> readOnly="true" strictValidation="true"
> xjcjar="tools/jwsdp-1.1/jaxb-1.0/lib/jaxb-xjc.jar">
> ...
> </bm:jaxb>
>
> <!-- Register services of that library, if any -->
> <register dir="build/classes/@{name}"
> excludes="**.test.*Test"
> ifTrue="@{register}">
> ...
> </register>
> </sequential>
> </macrodef>
>
> <ds:serversinfo id="blah">
> <ds:upload>
> <ds:primaryserver host="somehost.lgc.com">
> <ds:basedir location="\\%host%\dsbuilds"
> osFamily="windows" />
> <ds:basedir location="/net/%host%/blah/dsbuilds/${os}"
> osFamily="unix" unlessTrue="${denver}" />
> <ds:basedir location="/network/%host%/blah/dsbuilds/${os}"
> osFamily="unix" ifTrue="${denver}" />
> </ds:primaryserver>
> </ds:upload>
>
> <ds:download>
> <ds:server host="${defaultServerHost}">
> <ds:baseurl url="http://%host%/dsbuilds";
> osFamily="windows" />
> <ds:baseurl url="http://%host%/dsbuilds/${os}";
> osFamily="unix" />
> </ds:server>
> </ds:download>
> </ds:serversinfo>
>
> <module ... xmlns="antlib:com.lgc.decisionspace">
> ...
> <systempath>
> <element location="${bin.dir}" />
> <elementgroup ifTrue="${msdev}">
> <element location="plugin1/bin/${msdev.config}" />
> <element location="plugin2/bin/${msdev.config}" />
> <element location="plugin3/bin/${msdev.config}" />
> <element location="plugin4/bin/${msdev.config}" />
> </elementgroup>
> </systempath>
> </module>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
