Re: and s

Dominique Devienne wrote: I prefer to keep my build files shorter, as they are already definitely too long. Mine are actually quite small now that I all the common parts from a small set of 'abstract' build files. (and by 'abstract' I mean "meant to imported" as opposed to necessarily having 'abst

RE: and s

> I prefer to keep my build files shorter, as they are > already definitely too long. Mine are actually quite small now that I all the common parts from a small set of 'abstract' build files. (and by 'abstract' I mean "meant to imported" as opposed to necessarily having 'abstract' targets). > So

Re: and s

Jacob Kjome wrote: I also tend to define a path that is empty, but referenced by one of the other standard paths. That way, I can override that empty path and the pathelements will get included in the standard path by reference. Hopefully that's what you are looking for. Yes it is. Thanks everyone

Re: and s

Dominique Devienne wrote: Yeah, it should work. But I prefer to have a callable/complete common.xml. I guess that strikes me as strange. I've designed at least 3 quite large multiple-build-files Ant builds for mixed C/C++/Java projects using , and the build files I import are never callable directl

Re: and s

I've been specifying paths in an file which is loaded by the common build file and used by other build files by importing the common build file. All build files use the same build structure so the paths are always applicable to all builds. I also tend to define a path that is empty, but referenc

RE: and s

> -Original Message- > From: Stefano Mancarella [mailto:[EMAIL PROTECTED] > > Dominique Devienne wrote: > > Note that by putting the extension classpath before the , > > and removing the it from common.xml, this works fine, and has the > > advantage of failing the build is the importing bu

Re: and s

Dominique Devienne wrote: Note that by putting the extension classpath before the , and removing the it from common.xml, this works fine, and has the advantage of failing the build is the importing build file does not declare a path with the required ID. But it also makes the common build file inco

RE: and s

7;s more a side effect than by design, far from being either obvious or elegant, but it should work nonetheless (although I didn't try it). --DD > -Original Message- > From: Stefano Mancarella [mailto:[EMAIL PROTECTED] > Sent: Wednesday, October 06, 2004 7:09 AM > To: Ant

Re: and s

Peter Reilly wrote: This will cause the annoying Overriding previous definition of reference to classpath.additional message. Yeah. I already got that when I redefined the path. There is a bug report requesting the reduction of this message to verbose, perhaps this would be a good thing to do! I ag

Re: and s

[EMAIL PROTECTED] wrote: common.xml: --- The "classpath.additional" has to defined in the common.xml because its references there. So basically "classpath" has to be _prepared_ for extension by referencing another path ("classpath.additional") which I can overr