[Eclipse 3.3 + Ant 1.7] <javac> Classpath length on Windows XP
- From: Jethrie-JDuprez in the news <Jethrie@xxxxxxxxx>
- Date: Fri, 2 May 2008 01:03:19 -0700 (PDT)
Hello,
I'm using Ant from within Eclipse to build a project on developer
environment.
I define two <path> variables to hold different classpathes for
regular vs test classes, and accordingly define two targets "compile"
and "compiletests" to respectively compile the regular and the test
classes.
<path id="compile.class.path">
<fileset dir="${lib.dir}">
<include name="**.jar" />
</fileset>
<fileset dir="../${dependency1}">
<include name="**/*.jar" />
</fileset>
...
<pathelement location=...
</path>
<path id="test.class.path">
<path refid="compile.class.path" />
<pathelement location="${src.output.dir}" />
</path>
<target name="compile" depends="init">
<javac srcdir="${src.dir}" destdir="${src.output.dir}"
debug="on">
<classpath refid="src.class.path"/>
</javac>
</target>
<target name="compiletests" depends="init,compile">
<javac srcdir="${test.dir}" destdir="${test.output.dir}"
debug="on">
<classpath refid="test.class.path" />
</javac>
</target>
With pathes defined in that order, the compiletest target fails with
errors that suggest that the compiler doesn't find compiled classes
for regular sources (which are in ${src.output.dir}, which itself
appears at the end of the classpath of the "compiletest" <javac> task,
when run with "-v" trace flag).
If i switch the order in the definition of test.class.path, the build
succeeds:
<path id="test.class.path">
<pathelement location="${src.output.dir}" />
<path refid="compile.class.path" />
</path>
I tried in verbose and debug mode, and the only difference is, as
expected, the order of apparition of the src.output.dir in the
classpath argument of the <javac> task.
I assume that there is some limitation in the length of the path
supported by (either of Ant, Eclipse, WindowsXP, or a combination of
both), such that the compiler doesn't receive the end of the
classpath.
Is there any way to verify this hypothesis, such as somme additional
trace flag? And if confirmed, any way to make sure I can stuff an
arbitrarily long classpath?
Once the order switched, the build currently works (luckily the test
must not use some remote element of the compile.class.path), but of
course I can't bet it will always be the case.
Note that one of the reasons the classpath is so long is that it is
padded with numerous Eclipse jars. Thay may be necessary to the
integration of the Ant build within Eclipse, but they should not
appear in the classpath arg of the <javac> task itself, otherwise the
build run from Eclipse is no more equivalent to the command-line Ant
build.
Is there any way to remove these Eclipse jar files?
Thanks in advance.
Brgds,
J.
.
- Prev by Date: JOB POSTING: Subversion / CVS Admin
- Next by Date: Apache Tomcat/4.1.24 and Eclipse related issue
- Previous by thread: JOB POSTING: Subversion / CVS Admin
- Next by thread: Apache Tomcat/4.1.24 and Eclipse related issue
- Index(es):
Relevant Pages
|
|
