----- Rainer Noack wrote:
> just a hint:
> what's about <target/>'s if/unless attributes...
Both <target if=""> and <target unless=""> certainly have their uses.
And I don't hesitate to use them where it makes sense to do so. But I
haven't found that they really help much with managing dependencies or
other "tricky" aspects of our build architecture.
One example of my frustration during my attempts did involve using
"unless":
<target name="init" unless="init-done">
<property name="init-done" value="true">
<property file="${CONFIG}/dev.properties"/>
<property file="${CONFIG}/runtime.properties"/>
</target>
My intent was to ensure that the two .properties were only read once,
since I could see that my "init" target was being called over and over
(see the current thread with subject: "target dependencies"). This not
only slows things down, but it creates TONS of noise when using -verbose
to help debug scripts (since Ant whines non-stop about ignoring attempts
to redefine the properties which were previously set).
The problem with the above is that the "init-done" property isn't
persistent if an <antcall> or <ant> task was used. For example:
<target name="foo" depends="init"/>
<target name="bar" depends="init"/>
<antcall target="foo"/>
<antcall target="bar"/>
Both of these <antcall> tasks will result in the "init" target being
executed again, even if "init" was executed earlier in this same script.
<sigh>
----- Rainer Noack wrote:
> BTW: How would you handle this in eclipse?
We're using Eclipse 3.1. In the "Run" menu you can select "External
tools" -> "External tools...". From there you can specify an Ant script
as the "Buildfile", as well as what "Targets" to execute. This can be
saved (along with many other settings) as a named "Run Configuration"
which can be easily invoked from External Tools icon on the toolbar.
You can also use "Window" -> "Show View" -> "Ant" and add each build
file of interest to a tree-control showing available targets.
Right-clicking on a target allows it to be executed, but it's a bit
clunky. NetBeans did a better job of integrating with Ant at this level
in my opinion.
----- Jon Jagger wrote:
> <target name="com/wibblesoft/grammar/model" depends="....">
> <run-test-macro package="com/wibblesoft/grammar/model"/>
> </target>
>
> The target name is not available via a property hence the duplication
:-(
I agree that it would be *really* nice to have a way to eliminate this
type of redundancy!
> The package name doubles as the package-folder it comes from.
I initially tried to use this trick with the *project* name:
<project name="com/wibblesoft/grammar/model" ...>
<javac includes="${ant.project.name}" ...>
But the difficulty in translating paths (with "/" chrs) to package names
(with "." chrs) caused too many headaches.
Thanks for sharing your nested <macrodef> code, Jon. It's interesting
to see what other folks are doing to "get the job done".
----- Jon Jagger wrote:
> Now from the top level folder you can issue standard ant commands. Eg
> >ant com/wibblesoft/grammar/model
Huh. I think of "standard ant commands" like: compile, test and clean.
I find it really convenient to leverage the directory I'm already in.
In other words, I'd much rather use:
>cd com/wibblesoft/grammar/model
>ant build
This allows me to define various commands to operate on the "current"
package (e.g. clean, javadoc, etc).
----- Jon Jagger wrote:
> <target name="build-without-dependencies">
:
> <target name="build-with-dependencies">
Interesting. Instead of this, I've decided to use the equivalent of
"build-with-dependencies" and "build-everything" (I call them "build"
and "build-all").
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
