Ant oddity

[Martin Gregorie]

I've just been rearranging the way I construct and maintain the CLASSPATH
I use for compilations and testing code before it gets jarred up.

Along the way I found an oddity: I keep separate projects in their own
directory structures and, while most projects are happy with the new
CLASSPATH structure, one small one with all sources in a single directory
isn't. If I clear out the .class files and run "javac *.java" everything
works as expected, but if I compile it under ant, javac complains that a
list of non-existent jar files can't be found but still succeeds in
compiling everything, so it looks like an ant problem.

The jar files it is complaining do not appear in the CLASSPATH, though
they were in the previous version. I've even done a cold reboot to make
sure the old class path wasn't lurking in memory somewhere, but this one
project is still seeing them. It has no project-specific ant
configuration either. In consequence I've been tearing my hair out this
afternoon trying to discover where the old class part list might be
lurking: I didn't find anything useful at the ant site or in web
searching. Any suggestions gratefully received.

 

[John B. Matthews]

I've just been rearranging the way I construct and maintain the
CLASSPATH I use for compilations and testing code before it gets
jarred up.

Along the way I found an oddity: I keep separate projects in their
own directory structures and, while most projects are happy with the
new CLASSPATH structure, one small one with all sources in a single
directory isn't. If I clear out the .class files and run "javac
*.java" everything works as expected, but if I compile it under ant,
javac complains that a list of non-existent jar files can't be found
but still succeeds in compiling everything, so it looks like an ant
problem.

The jar files it is complaining do not appear in the CLASSPATH,
though they were in the previous version. I've even done a cold
reboot to make sure the old class path wasn't lurking in memory
somewhere, but this one project is still seeing them. It has no
project-specific ant configuration either. In consequence I've been
tearing my hair out this afternoon trying to discover where the old
class part list might be lurking: I didn't find anything useful at
the ant site or in web searching. Any suggestions gratefully
received.

You might check for strays in the assorted java.ext.dirs and for
conformal paths in the <javac/> srcdir/destdir attributes:

<http://ant.apache.org/faq.html#always-recompiles>

If it helps, here's my minimal, one-class, default-package, ant-based
project:

<https://sites.google.com/site/drjohnbmatthews/manifesto>

 

[Martin Gregorie]

You might check for strays in the assorted java.ext.dirs and for

There's nothing in plain text files here. and running 'ant --execdebug'
isn't showing the invalid jar file references.

I looked at the META-INF files in the directories in the jar files in
$sdk/jre/lib/ext - nothing there either.

conformal paths in the <javac/> srcdir/destdir attributes:

<http://ant.apache.org/faq.html#always-recompiles>

Thanks for that, but it didn't help either. I'd previously scanned the
FAQ but found nothing relevant.

If it helps, here's my minimal, one-class, default-package, ant-based
project:

<https://sites.google.com/site/drjohnbmatthews/manifesto>

Thanks. Compiling this is also causing javac to list the invalid jarfile
references(!). Mysteriously, these spurious reports don't appear when I
recompile my library of support classes. This is in the same user: it
does not have any local ~/.ant* directories and hence no local ant
configuration files.

This has driven me to build a brute force script which scans a directory
structure with find and runs grep against every readable regular file,
i.e. those that match find's " -type f -readable " selectors. It will
also scan every file except those in /proc, /selinux and /sys (excluded
since checking them blocked or crashed grep).

Consequently, having looked at all files that matched 'xstream\.jar', I
can say that there are no references to /home/java/jarlib/xstream.jar in
any searchable file.

/home/java/jarlib/xstream.jar is one of the files that was being reported
as missing: correctly so since there's no longer a file of that name in
the class path or in the filing system.

That's not to say that there isn't one in a compressed file, but unless
ant does something really silly like putting the existing class path in
one of its jar files when its installed, I don't believe its there either.

I seems safe to assume that anything causing the problem must be ant-
associated since its possible to compile Manifesto with 'javac *.java'
without the complaints but using ant and its unmodified build.xml throws
up the complaints despite, according to ant, they are being reported by
javac, not ant.

 

[John B. Matthews]

There's nothing in plain text files here. and running 'ant --execdebug'
isn't showing the invalid jar file references.

I hadn't noticed --execdebug before; thanks!

I looked at the META-INF files in the directories in the jar files in
$sdk/jre/lib/ext - nothing there either.

Thanks for that, but it didn't help either. I'd previously scanned the
FAQ but found nothing relevant.

Thanks. Compiling this is also causing javac to list the invalid
jarfile references(!). Mysteriously, these spurious reports don't
appear when I recompile my library of support classes. This is in the
same user: it does not have any local ~/.ant* directories and hence
no local ant configuration files.

This has driven me to build a brute force script which scans a
directory structure with find and runs grep against every readable
regular file, i.e. those that match find's " -type f -readable "
selectors. It will also scan every file except those in /proc,
/selinux and /sys (excluded since checking them blocked or crashed
grep).

Consequently, having looked at all files that matched 'xstream\.jar',
I can say that there are no references to
/home/java/jarlib/xstream.jar in any searchable file.

/home/java/jarlib/xstream.jar is one of the files that was being
reported as missing: correctly so since there's no longer a file of
that name in the class path or in the filing system.

That's not to say that there isn't one in a compressed file, but
unless ant does something really silly like putting the existing
class path in one of its jar files when its installed, I don't
believe its there either.

I seems safe to assume that anything causing the problem must be ant-
associated since its possible to compile Manifesto with 'javac
*.java' without the complaints but using ant and its unmodified
build.xml throws up the complaints despite, according to ant, they
are being reported by javac, not ant.

I tried the Manifesto project on Ubuntu and saw nothing untoward. I
noticed that --execdebug showed an empty classpath: -cp "". Does the
-noclasspath option reveal anything?

<http://ant.apache.org/manual/running.html#libs>

 

[Martin Gregorie]

I tried the Manifesto project on Ubuntu and saw nothing untoward. I
noticed that --execdebug showed an empty classpath: -cp "". Does the
-noclasspath option reveal anything?

Nothing useful. Manifesto builds OK with and without --noclasspath and
still insists on complaining about the non-existent jar files.

I'm unsurprised that you would have an empty classpath while I don't: I
have a script in /etc/profile.d that sets up environment variables used
by Java, e.g. JAVA_HOME and ANT_HOME, adds these to PATH and builds and
exports CLASSPATH for compilation purposes.

All support jar files are symlinks in a single flat directory. I wrote a
script that deletes and replaces the list of symlinks and then generates
the matching setup script from a config file that lists the support
packages I'm using and says where the package jar file(s) can be found
(the mstor package includes seven additional jar files for its
dependencies.

<http://ant.apache.org/manual/running.html#libs>

I've just run ant using the -verbose and -debug options which didn't
help: the one of the unwanted jar files is only mentioned in the javac
error message - it doesn't appear in any of the ant tracing information.

I'm running ant 1.7.1 - I wonder if an upgrade to 1.8.1 is likely to help.

 

[John B. Matthews]

I'm unsurprised that you would have an empty classpath while I don't: I
have a script in /etc/profile.d that sets up environment variables used
by Java, e.g. JAVA_HOME and ANT_HOME, adds these to PATH and builds and
exports CLASSPATH for compilation purposes.

I commented out my `export CLASSPATH` in favor of per-project settings.
Now that I look, I'm also letting NetBeans, Eclipse and Mac OS manage
paths that used to be defined in JAVA_HOME. I still export ANT_HOME,
CATALINA_HOME, DERBY_HOME, etc.

All support jar files are symlinks in a single flat directory. I wrote a
script that deletes and replaces the list of symlinks and then generates
the matching setup script from a config file that lists the support
packages I'm using and says where the package jar file(s) can be found
(the mstor package includes seven additional jar files for its
dependencies.


I've just run ant using the -verbose and -debug options which didn't
help: the one of the unwanted jar files is only mentioned in the javac
error message - it doesn't appear in any of the ant tracing information.

I'm running ant 1.7.1 - I wonder if an upgrade to 1.8.1 is likely to help.

I'm using 1.7.1 on Ubuntu 10.04.1 LTS and 1.8.1 on Mac OS X 10.5.8.
Neither shell exports CLASSPATH and both ants show -cp "".

Could this be something engendered by a Service Provider?

<http://download.oracle.com/javase/tutorial/sound/SPI-intro.html>

 

[Martin Gregorie]

I commented out my `export CLASSPATH` in favor of per-project settings.
Now that I look, I'm also letting NetBeans, Eclipse and Mac OS manage
paths that used to be defined in JAVA_HOME. I still export ANT_HOME,
CATALINA_HOME, DERBY_HOME, etc.

I'm not using IDEs at all, so its not altogether obvious how I'd manage
per-project class paths.

However, the problem remains: where is ant getting the junk from since
its not showing it on any debugging output? And, why does it only happen
for some projects in the same user?

All projects are essentially the same -the only thing that makes them
into projects is the presence of a build.xml file, which are all fairly
much the same and all hand-created, and each is a separate CVS module.

Could this be something engendered by a Service Provider?

<http://download.oracle.com/javase/tutorial/sound/SPI-intro.html>

To the best of my knowledge there are none on the box: I certainly
haven't created or installed any. This is a fairly bog-standard ThinkPad
laptop running Fedora 12.

Tomorrow I'll apply the same set-up to my home server, which is actually
my main development system and runs Fedora 13, and see what happens. At
least I know its safe in that Java programs still compile and run
successfully despite the spurious warning messages. If its still present
there, I'll upgrade both computers to ant 1.8.1 and, if that doesn't get
rid of the warnings, I think it may be time to raise a bug with the good
folks at ASF.

....and all because I wanted to move my mail archive system from mstor
0.9.11 to mstor 0.9.12 and realised my jar file management system was
getting out of hand.

 

[Martin Gregorie]

Tomorrow I'll apply the same set-up to my home server, which is actually
my main development system and runs Fedora 13, and see what happens. At
least I know its safe in that Java programs still compile and run
successfully despite the spurious warning messages. If its still present
there, I'll upgrade both computers to ant 1.8.1 and, if that doesn't get
rid of the warnings, I think it may be time to raise a bug with the good
folks at ASF.

Done, but it took a bit of fiddling.

I ended up installing ant 1.8.1 and adding the 'includeAntRuntime'
attribute, which is now mandatory, to all javac tasks. This has mitigated
the problem but not caused it to vanish entirely: there are now only one
or two projects that show the warning about not finding spurious jar
files and only one warning per affected javac task.

At least I now have a jar library management tool cum classpath generator
that I'm happy with.

I also learnt that if you're going to hold all jar files in a single
directory (i.e. a flat structure), while its OK to satisfy dependencies
with symlinks to the jar files needed to satisfy them, you MUST NOT
symlink the jar file(s) referenced by the -jar option because their
symlink chain will be followed to the directory holding the real jar file
where, of course, its dependencies can't be satisfied.

I didn't find anything about this in the documentation for either jar
files or the jar utility: did I miss seeing it?

 

[John B. Matthews]

Done, but it took a bit of fiddling.

I ended up installing ant 1.8.1 and adding the 'includeAntRuntime'
attribute, which is now mandatory, to all javac tasks. This has
mitigated the problem but not caused it to vanish entirely: there are
now only one or two projects that show the warning about not finding
spurious jar files and only one warning per affected javac task.

Any chance they use(d) something that depends on Xstream, such as
Launch4J? Also, you might use your package manager to examine the
dependencies for ant: `yum deplist ant`, IIRC.

At least I now have a jar library management tool cum classpath generator
that I'm happy with.

[...]

 

[Martin Gregorie]

Any chance they use(d) something that depends on Xstream, such as
Launch4J?

No, I don't use that.

Also, you might use your package manager to examine the
dependencies for ant: `yum deplist ant`, IIRC.

That's not relevant. Fedora installs OpenJava, but I'm using Sun Java. It
and all its support stuff (extra packages, ant) are installed outside the
package system and the usual directories: they are all in /home/java.

/usr/java is a symlink pointing at /home/java. I use this set-up because
this lets my Java environment survive a clean Linux install. I don't
reformat the /home partition and so, by reinserting the symlink and
dropping java.sh into /etc/profile.d Java is instantly available and
working. java.sh is run during login to set up the Java environment
variables and add the Java and ant binary directories to PATH.

In any case the Fedora 12 ant package is 1.7.1 while I'm now running
1.8.1.

But, as I say, these warnings would seem to be spurious because the
compiles all finish without errors and the programs run correctly,
regardless of whether they are run using class files in the development
directory or from the jar file containing them.

I've even tried deleting .cache and .ccache in the development
directories without effect.