ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John5342 <>
Subject Re: what does ant really use?
Date Wed, 08 Oct 2008 09:58:19 GMT
If you changed the name of gcj and javac in /usr/bin they are not the
actualy executables. They are only links to the real ones which in fedora
(and probably RH) located in /usr/share/jvm/<java implementation>/bin/. In
fedora (and again probably in RH) there is an "alternatives" application
which allows you to choose which installed version of java you are using
rather than renaming binaries. Should also warn you that although RH is
supported longer than most and in general rock stable the software is often
quite old because i happen to know that more recent versions of gcj support
java 1.5. Hope this all helps you in the right direction.

2008/10/8 Pareti, Joseph <>

> As a disclaimer, I am a true ant (and java) novice. Having said that, I am
> confronted with a weird problem in a j2ee project which fails at run time
> with a jndi error. After several investigations, I am now almost convinced
> it has to do with the build process.
> I have jdk 1.5.0_02 installed on my system, x86/RHEL 3, kernel 2.4; I am
> also using ant 1.5.2_23
> My build log file shows, for each compile target the following message:
> [javac] Using gcj compiler
> Just for kicks, I then deleted gcj as well as javac (here I mean the javac
> compiler executable) from my disk i.e. I renamed both of them to something
> else, and ant still worked and still claimed it's using gcj, which leaves me
> totally confused.
> Perhaps one hint; at the top of the log file I see the comment "detected
> java version 1.4 in /usr".
> I know this is not what I want/need (it should be 1.5), so where does it
> come from?
> I then went ahead setting the following property in my build.xml:
> <property name="build.compiler" value="modern"/>
> but this was quickly discarded:
> "Override ignored for property build.compiler"
> which basically produced the same results as described above. I am running
> out of ideas here.
> Thanks for any insights.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message