Re[2]: Best practice for numerous javac calls?

[Jacob Kjome <ho...@visi.com>]

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:jakarta-ant@ehatchersolutions.com] 
>> 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:   <ma...@jakarta.apache.org>
>> > For additional commands, e-mail: 
>> <ma...@jakarta.apache.org>
>> > 
>> > 
>> > 
>> 
>> 
>> --
>> To 
>> unsubscribe, e-mail:   
>> <mailto:ant-user-> unsubscribe@jakarta.apache.org>
>> For 
>> additional commands, 
>> e-mail: <ma...@jakarta.apache.org>
>> 

SA> --
SA> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
SA> For additional commands, e-mail: <ma...@jakarta.apache.org>



-- 
Best regards,
 Jacob                            mailto:hoju@visi.com


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>