I see. Your main problem seems to be the use of <antcall>. This starts a "new" project. You can pass the properties in the new project but not back to the (calling) main project. Also the dependencies are resolved again (Same as considered in the thread "target dependencies" and documented implicitely in <antcall>). If I were You, I would try to avoid the use of <antcall> or to use it without "global" dependencies, i.e. totally controlled from the main script. Cheers Rainer
> -----Original Message----- > From: Michael Cepek [mailto:[EMAIL PROTECTED] > Sent: Wednesday, May 18, 2005 3:57 PM > To: Ant Users List > Subject: RE: nontrivial dependencies > > > ----- 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
