Ant oddity

Discussion in 'Java' started by Martin Gregorie, Nov 14, 2010.

  1. 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.


    --
    martin@ | Martin Gregorie
    gregorie. | Essex, UK
    org |
    Martin Gregorie, Nov 14, 2010
    #1
    1. Advertising

  2. In article <ibpfsp$9eb$>,
    Martin Gregorie <> wrote:

    > 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>

    --
    John B. Matthews
    trashgod at gmail dot com
    <http://sites.google.com/site/drjohnbmatthews>
    John B. Matthews, Nov 14, 2010
    #2
    1. Advertising

  3. On Sun, 14 Nov 2010 18:38:45 -0500, John B. Matthews wrote:

    > 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.


    --
    martin@ | Martin Gregorie
    gregorie. | Essex, UK
    org |
    Martin Gregorie, Nov 16, 2010
    #3
  4. In article <ibv0k2$l33$>,
    Martin Gregorie <> wrote:

    > On Sun, 14 Nov 2010 18:38:45 -0500, John B. Matthews wrote:
    >
    > > 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 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.
    >
    > > 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.


    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>

    --
    John B. Matthews
    trashgod at gmail dot com
    <http://sites.google.com/site/drjohnbmatthews>
    John B. Matthews, Nov 17, 2010
    #4
  5. On Tue, 16 Nov 2010 21:52:23 -0500, John B. Matthews wrote:

    > 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.


    --
    martin@ | Martin Gregorie
    gregorie. | Essex, UK
    org |
    Martin Gregorie, Nov 17, 2010
    #5
  6. In article <ic0f0e$uic$>,
    Martin Gregorie <> wrote:

    > On Tue, 16 Nov 2010 21:52:23 -0500, John B. Matthews wrote:
    >
    > > --execdebug showed an empty classpath: -cp "".

    >
    > 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.
    >
    > > <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.


    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>

    --
    John B. Matthews
    trashgod at gmail dot com
    <http://sites.google.com/site/drjohnbmatthews>
    John B. Matthews, Nov 17, 2010
    #6
  7. On Wed, 17 Nov 2010 17:28:59 -0500, John B. Matthews wrote:

    > 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@ | Martin Gregorie
    gregorie. | Essex, UK
    org |
    Martin Gregorie, Nov 17, 2010
    #7
  8. On Wed, 17 Nov 2010 23:07:38 +0000, Martin Gregorie wrote:

    > 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?


    --
    martin@ | Martin Gregorie
    gregorie. | Essex, UK
    org |
    Martin Gregorie, Nov 21, 2010
    #8
  9. In article <icc6mr$ssa$>,
    Martin Gregorie <> wrote:

    > On Wed, 17 Nov 2010 23:07:38 +0000, Martin Gregorie wrote:
    >
    > > 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.


    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.


    [...]

    --
    John B. Matthews
    trashgod at gmail dot com
    <http://sites.google.com/site/drjohnbmatthews>
    John B. Matthews, Nov 22, 2010
    #9
  10. On Mon, 22 Nov 2010 09:47:13 -0500, John B. Matthews wrote:

    > In article <icc6mr$ssa$>,
    > Martin Gregorie <> wrote:
    >
    >> On Wed, 17 Nov 2010 23:07:38 +0000, Martin Gregorie wrote:
    >>
    >> > 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.

    >
    > 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.


    --
    martin@ | Martin Gregorie
    gregorie. | Essex, UK
    org |
    Martin Gregorie, Nov 23, 2010
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    3
    Views:
    509
  2. Chris Bedford
    Replies:
    6
    Views:
    2,207
  3. john martin
    Replies:
    2
    Views:
    2,200
    john martin
    Apr 7, 2005
  4. Replies:
    1
    Views:
    483
    Larry
    Mar 7, 2006
  5. Replies:
    6
    Views:
    854
Loading...

Share This Page