Looking for a task that verifies the existance of a class on the system, I
found the 'available' task doing *almost* what I needed. The missing feature
was to stop the build if the class was not available.
Using only the existing features of task 'available', this lead to code like:
<target name="require-mylogger"
depends="check-mylogger,need-mylogger,need-log4j" />
<target name="check-mylogger">
<available property="mylogger" classname="mylogger.Logger" />
<available property="log4j" classname="org.log4j.Category" />
</target>
<target name="need-mylogger" unless="mylogger">
<fail message="Required 'mylogger' not found" />
</target>
<target name="need-log4j" unless="log4j">
<fail message="Required 'log4j' not found" />
</target>
All this just to stop the build if one of the required packages was not
available.
What I really want to do is something like
<require classname="mylogger.Logger" />
<require classname="org.log4j.Category" />
and get a BuildException when the class is not available on the classpath. I
know I
can specify the classpath in the build script, but that does not verify the real
availability of the classes.
I see three options, my question is which one to select:
1) Live with the existing features, but this leads to complex code for a very
simple
requirement when the number of classes needed grows.
2) Develop a task called 'require' that does exactly what I want. Easy, but
99.9% of the
code exists already in the 'available' task. This leads to:
<require classname="mylogger.Logger" />
3) Add a boolean attribute 'required' to the existing 'available' task, false
by default
to be backward compatible. Easy, but not my code to change. This leads to:
<available property="mylogger" classname="mylogger.Logger"
required="true" />
I don't like the first, the second means I would be stealing code from
'available', the
third I like most, keeping the number of almost similar tasks to a minimum, but
is this
useful and/or acceptable to others (the original developer, for example) ?
Please advise on the way to go in this and similar cases where a bit more
functionality
could make existing code more useful, although the audience for the feature may
be limited.
