I have this issue when I use a <ant> to call another build file. I specify <ant inheritAll="false" target="sometarget" dir="/some/dir">. I don't specify inheritRefs because it defaults to false. Yet, when I define a custom taskdef in the called file, I get a message saying that I am overriding the a previous definition of a taskdef. I had defined it in the calling build file and ran some stuff, but since I have inheritAll="false" and inheritRefs is false by default, why should it be redefining anything?
I can't use any workaround in the called build file that creates a dependency on the calling build file because the called build file must be able to be run directly without reference to the calling build file. Calling the build file using <ant> is purely there for convenience and central control over the whole build system. Each build file, however, is meant to be self-sufficient with no dependencies other than common properties file which each build file references. Any solutions to that? Jake Monday, December 02, 2002, 3:48:53 PM, you wrote: SA> Ah, this is what I need: SA> <reference refid="anttask.compile.classpath" SA> torefid="compile.classpath"/> SA> Thanks Erik! SA> -- Steve SA> // WRQ has 21 years of experience providing integration software and SA> // services for host-intensive environments. To learn more about our SA> // Reflection and Verastream products, visit http://www.wrq.com/products/ >> -----Original Message----- >> From: Erik Hatcher [mailto:[EMAIL PROTECTED]] >> Sent: Monday, December 02, 2002 12:13 PM >> To: Ant Users List >> Subject: Re: Best practice for numerous javac calls? >> >> >> I do this very thing in my sample project: >> >> http://www.ehatchersolutions.com/downloads/ >> >> (get the latest version, whatever that happens to be at the time) >> >> Look at my build.xml and how I use <antcall>. I do not override >> references, I just create a new reference for that particular call. >> >> Erik >> >> >> Steve Allan wrote: >> > Hi, >> > >> > I hava a java project where all the different components >> are under one >> > source root. To accommodate the developers' request to be able to >> > build certain subsections of the code and their dependencies, there >> > are 10 different compile targets. To avoid duplicating all the >> > <javac> calls, I wrote a single compile-java target with >> the idea that >> > a component's compile target could define the java source >> and classpath, and >> > then call the java-compile target. Here's a typical example: >> > >> > <target name = "utils" depends = "init"> >> > <!-- define classpath --> >> > <path id = "compile.classpath"> >> > <pathelement location = "${jaas.jar}"/> >> > </path> >> > >> > <!-- define source patternset --> >> > <patternset id = "java.src"> >> > <include name = "${my.package.root}/util/**/*.java"/> >> > <include name = "${my.package.root}/include/**/*.java"/> >> > </patternset> >> > >> > <!-- compile classes --> >> > <antcall target = "java-compile" inheritrefs = "true"/> >> > </target> >> > >> > And the java-compile target looks like this: >> > >> > <target name = "java-compile"> >> > <javac destdir = "${build.classes.dir}" >> > srcdir = "${src.dir}" >> > ... >> > > >> > <classpath refid = "compile.classpath"/> >> > <patternset refid = "java.src"/> >> > </javac> >> > </target> >> > >> > >> > This works, but if I build all my components in one call to ant, I >> > keep getting messages about redefining references: >> > >> > Overriding previous definition of reference to compile.classpath >> > Overriding previous definition of reference to java.src >> > >> > So I'm wondering >> > >> > 1) Is redefining a reference a 'bad thing'? >> > 2) Is there a better way to achieve this type of granularity in the >> > compile targets? >> > >> > Thanks. >> > >> > -- Steve >> > // WRQ has 21 years of experience providing integration software and >> > // services for host-intensive environments. To learn more about our >> > // Reflection and Verastream products, visit >> http://www.wrq.com/products/ >> > >> > >> > -- >> > To unsubscribe, >> e-mail: <mailto:[EMAIL PROTECTED]> >> > For additional commands, e-mail: >> <mailto:[EMAIL PROTECTED]> >> > >> > >> > >> >> >> -- >> To >> unsubscribe, e-mail: >> <mailto:ant-user-> [EMAIL PROTECTED]> >> For >> additional commands, >> e-mail: <mailto:[EMAIL PROTECTED]> >> SA> -- SA> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> SA> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- Best regards, Jacob mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>