Groovy
  1. Groovy
  2. GROOVY-2258

AntBuilder broken by a RC-1 -> RC-2 change: Can't find compiler

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: 1.1-rc-2
    • Fix Version/s: 1.1-rc-3
    • Component/s: None
    • Labels:
      None
    • Environment:
      Ubuntu 7.10 Gutsy Gibbon, java version "1.6.0_03", Groovy Head r8979

      Description

      After a clean compile and install of Groovy and a clean compile and install of Gant then when Gant tries to process a javac Ant task, the following output is generated:

      > gant test
      [groovyc] No sources to compile
      [mkdir] Created dir: /home/Checkouts/Subversion/Gant/gant/trunk/target/test-classes
      [javac] Compiling 1 source file to /home/Checkouts/Subversion/Gant/gant/trunk/target/classes
      Unable to find a javac compiler;
      com.sun.tools.javac.Main is not on the classpath.
      Perhaps JAVA_HOME does not point to the JDK.
      It is currently set to "/usr/lib/jvm/java-6-sun-1.6.0.03/jre"
      > echo $JAVA_HOME
      /usr/lib/jvm/java-6-sun-1.6.0.03
      >

        Activity

        Hide
        Jochen Theodorou added a comment -

        Is this a blocker for gant, or for groovy?

        besides that.... is it possible, that the gant script sets a new JAVA_HOME?

        Show
        Jochen Theodorou added a comment - Is this a blocker for gant, or for groovy? besides that.... is it possible, that the gant script sets a new JAVA_HOME?
        Hide
        Russel Winder added a comment -

        I beleive this is a blocker for both Gant and Groovy. I believe this problem has arisen due to a change in Groovy over the last three or four weeks.

        Gant does not alter the JAVA_HOME variable:

        > grep -r JAVA src
        >

        Of the Ant tasks used in the Gant build, only the Ant.javac task appears to be affected, the Ant.groovyc, Ant.junit tasks appears to work just fine.

        Show
        Russel Winder added a comment - I beleive this is a blocker for both Gant and Groovy. I believe this problem has arisen due to a change in Groovy over the last three or four weeks. Gant does not alter the JAVA_HOME variable: > grep -r JAVA src > Of the Ant tasks used in the Gant build, only the Ant.javac task appears to be affected, the Ant.groovyc, Ant.junit tasks appears to work just fine.
        Hide
        Jochen Theodorou added a comment -

        hmm.. if I see it right, the gant script starts the startGroovy script, which means the error should be there. There I find only this suspicious part:

        # Attempt to set JAVA_HOME if it's not already set.
        if [ -z "$JAVA_HOME" ] ; then
            if $darwin ; then 
                [ -z "$JAVA_HOME" -a -d "/Library/Java/Home" ] && export JAVA_HOME="/Library/Java/Home"
                [ -z "$JAVA_HOME" -a -d "/System/Library/Frameworks/JavaVM.framework/Home" ] && export JAVA_HOME="/System/Library/Frameworks/JavaVM.framework/Home"
            else
                javaExecutable="`which javac`"
                [ -z "$javaExecutable" -o "`expr \"$javaExecutable\" : '\([^ ]*\)'`" = "no" ] && die "JAVA_HOME not set and cannot find javac to deduce location, please set JAVA_HOME."
                # readlink(1) is not available as standard on Solaris 10.
                readLink=`which readlink`
                [ `expr "$readLink" : '\([^ ]*\)'` = "no" ] && die "JAVA_HOME not set and readlink not available, please set JAVA_HOME."
                javaExecutable="`readlink -f \"$javaExecutable\"`"
                javaHome="`dirname \"$javaExecutable\"`"
                javaHome=`expr "$javaHome" : '\(.*\)/bin'`
                export JAVA_HOME="$javaHome"
            fi
        fi
        

        but If I recall correctly, then [ -z "$JAVA_HOME" ] ; is used to est for an unset variable (or zero length), which means that JAVA_HOME was not set before. Could you in your example give the output to the following program?

        which javac
        echo $JAVA_HOME
        gant test
        echo $JAVA_HOME
        

        because I expect now, that JAVA_HOME was first not set and is then set by the startGroovy script, but to the wrong location, because.. well because I think that "which javac" finds the the jre instead of the jdk. If that is correct, then setting PATH differently would help, as well as setting JAVA_HOME before.

        Show
        Jochen Theodorou added a comment - hmm.. if I see it right, the gant script starts the startGroovy script, which means the error should be there. There I find only this suspicious part: # Attempt to set JAVA_HOME if it's not already set. if [ -z "$JAVA_HOME" ] ; then if $darwin ; then [ -z "$JAVA_HOME" -a -d "/Library/Java/Home" ] && export JAVA_HOME= "/Library/Java/Home" [ -z "$JAVA_HOME" -a -d "/ System /Library/Frameworks/JavaVM.framework/Home" ] && export JAVA_HOME= "/ System /Library/Frameworks/JavaVM.framework/Home" else javaExecutable= "`which javac`" [ -z "$javaExecutable" -o "`expr \" $javaExecutable\ " : '\([^ ]*\)'`" = "no" ] && die "JAVA_HOME not set and cannot find javac to deduce location, please set JAVA_HOME." # readlink(1) is not available as standard on Solaris 10. readLink=`which readlink` [ `expr "$readLink" : '\([^ ]*\)'` = "no" ] && die "JAVA_HOME not set and readlink not available, please set JAVA_HOME." javaExecutable= "`readlink -f \" $javaExecutable\ "`" javaHome= "`dirname \" $javaExecutable\ "`" javaHome=`expr "$javaHome" : '\(.*\)/bin'` export JAVA_HOME= "$javaHome" fi fi but If I recall correctly, then [ -z "$JAVA_HOME" ] ; is used to est for an unset variable (or zero length), which means that JAVA_HOME was not set before. Could you in your example give the output to the following program? which javac echo $JAVA_HOME gant test echo $JAVA_HOME because I expect now, that JAVA_HOME was first not set and is then set by the startGroovy script, but to the wrong location, because.. well because I think that "which javac" finds the the jre instead of the jdk. If that is correct, then setting PATH differently would help, as well as setting JAVA_HOME before.
        Hide
        Russel Winder added a comment - - edited

        The problem here is that I have a JAVA_HOME set so none of the above code should get executed.

        > which javac
        /usr/lib/jvm/java-6-sun-1.6.0.03/bin/javac
        > echo $JAVA_HOME
        /usr/lib/jvm/java-6-sun-1.6.0.03
        > gant test
        [javac] Compiling 3 source files to /home/Checkouts/Subversion/Gant/gant/trunk/target/classes
        Unable to find a javac compiler;
        com.sun.tools.javac.Main is not on the classpath.
        Perhaps JAVA_HOME does not point to the JDK.
        It is currently set to "/usr/lib/jvm/java-6-sun-1.6.0.03/jre"
        > echo $JAVA_HOME
        /usr/lib/jvm/java-6-sun-1.6.0.03
        >

        executing the Gant script with -x, I see that:

        exec /usr/lib/jvm/java-6-sun-1.6.0.03/bin/java -classpath /home/users/russel/lib/Java/groovy/lib/groovy-1.1-rc-2-SNAPSHOT.jar -Dprogram.name=gant -Dgroovy.starter.conf=/home/users/russel/lib/Java/groovy/conf/groovy-starter.conf -Dgroovy.home=/home/users/russel/lib/Java/groovy -Dtools.jar=/usr/lib/jvm/java-6-sun-1.6.0.03/lib/tools.jar org.codehaus.groovy.tools.GroovyStarter --main gant.Gant --conf /home/users/russel/lib/Java/groovy/conf/groovy-starter.conf --classpath .

        all of which seems entirely fine.

        Thre string jre doesn't appear in the Gant source. In the Groovy source it appears in src/main/org/codehaus/groovy/tools/javac/JavacJavaCompiler.java and src/bin/startGroovy

        Show
        Russel Winder added a comment - - edited The problem here is that I have a JAVA_HOME set so none of the above code should get executed. > which javac /usr/lib/jvm/java-6-sun-1.6.0.03/bin/javac > echo $JAVA_HOME /usr/lib/jvm/java-6-sun-1.6.0.03 > gant test [javac] Compiling 3 source files to /home/Checkouts/Subversion/Gant/gant/trunk/target/classes Unable to find a javac compiler; com.sun.tools.javac.Main is not on the classpath. Perhaps JAVA_HOME does not point to the JDK. It is currently set to "/usr/lib/jvm/java-6-sun-1.6.0.03/jre" > echo $JAVA_HOME /usr/lib/jvm/java-6-sun-1.6.0.03 > executing the Gant script with -x, I see that: exec /usr/lib/jvm/java-6-sun-1.6.0.03/bin/java -classpath /home/users/russel/lib/Java/groovy/lib/groovy-1.1-rc-2-SNAPSHOT.jar -Dprogram.name=gant -Dgroovy.starter.conf=/home/users/russel/lib/Java/groovy/conf/groovy-starter.conf -Dgroovy.home=/home/users/russel/lib/Java/groovy -Dtools.jar=/usr/lib/jvm/java-6-sun-1.6.0.03/lib/tools.jar org.codehaus.groovy.tools.GroovyStarter --main gant.Gant --conf /home/users/russel/lib/Java/groovy/conf/groovy-starter.conf --classpath . all of which seems entirely fine. Thre string jre doesn't appear in the Gant source. In the Groovy source it appears in src/main/org/codehaus/groovy/tools/javac/JavacJavaCompiler.java and src/bin/startGroovy
        Hide
        Jochen Theodorou added a comment -

        I get the feeling that the startup scripts are ok, but that the discovery mechanism for the javac task in the ant lib is a bit broken... just to be absolutely sure that it is no Groovy. Could you execute a gant script containing this code:

        println (System.getenv("JAVA_HOME"))
        

        if this still prints usr/lib/jvm/java-6-sun-1.6.0.03 instead of the JRE version, then it can't be a startup related problem. Then it is either antbuilder, or ant itself.

        Show
        Jochen Theodorou added a comment - I get the feeling that the startup scripts are ok, but that the discovery mechanism for the javac task in the ant lib is a bit broken... just to be absolutely sure that it is no Groovy. Could you execute a gant script containing this code: println ( System .getenv( "JAVA_HOME" )) if this still prints usr/lib/jvm/java-6-sun-1.6.0.03 instead of the JRE version, then it can't be a startup related problem. Then it is either antbuilder, or ant itself.
        Hide
        Russel Winder added a comment -
        > more build.gant
        println (System.getenv("JAVA_HOME"))
        > gant
        /usr/lib/jvm/java-6-sun-1.6.0.03
        Target default does not exist.
        >

        I would be surprised if it was an Ant issue, I have been using 1.7.0 for many moons.

        Show
        Russel Winder added a comment - > more build.gant println (System.getenv("JAVA_HOME")) > gant /usr/lib/jvm/java-6-sun-1.6.0.03 Target default does not exist. > I would be surprised if it was an Ant issue, I have been using 1.7.0 for many moons.
        Hide
        Jochen Theodorou added a comment -

        it might be right that you are using ant 1.7.0 for a long time now, but as you can see groovy is not setting a different JAVA_HOME here. So it might be the combination that causes a problem. Looking at the code of AntBuilder I can't find anything that could cause this problem. That leaves it to the javac task.

        Show
        Jochen Theodorou added a comment - it might be right that you are using ant 1.7.0 for a long time now, but as you can see groovy is not setting a different JAVA_HOME here. So it might be the combination that causes a problem. Looking at the code of AntBuilder I can't find anything that could cause this problem. That leaves it to the javac task.
        Hide
        Russel Winder added a comment - - edited

        I suspect we must continue to doubt Groovy and that the change is a thing that has happened in Groovy.

        I assume AntBuilder does not fork Ant jobs but loads the Ant jars and calls the appropriate methods. This would mean that the environment variables are not an issue, that the problem is a classpath and class loaders issues. So what can have changed in Groovy that means that tools.jar is not on the classpath for AntBuilder?

        Show
        Russel Winder added a comment - - edited I suspect we must continue to doubt Groovy and that the change is a thing that has happened in Groovy. I assume AntBuilder does not fork Ant jobs but loads the Ant jars and calls the appropriate methods. This would mean that the environment variables are not an issue, that the problem is a classpath and class loaders issues. So what can have changed in Groovy that means that tools.jar is not on the classpath for AntBuilder?
        Hide
        Russel Winder added a comment -

        OK, this is definitely not a Gant problem The script:

        new AntBuilder ( ).javac ( srcdir : '.' , destdir : '/tmp' )
        

        causes the result:

        > groovy AntBuilderProblem.groovy
        [javac] Compiling 17 source files to /tmp
        Caught: : Unable to find a javac compiler;
        com.sun.tools.javac.Main is not on the classpath.
        Perhaps JAVA_HOME does not point to the JDK.
        It is currently set to "/usr/lib/jvm/java-6-sun-1.6.0.03/jre"
        at AntBuilderProblem.run(AntBuilderProblem.groovy:1)
        at AntBuilderProblem.main(AntBuilderProblem.groovy)

        Show
        Russel Winder added a comment - OK, this is definitely not a Gant problem The script: new AntBuilder ( ).javac ( srcdir : '.' , destdir : '/tmp' ) causes the result: > groovy AntBuilderProblem.groovy [javac] Compiling 17 source files to /tmp Caught: : Unable to find a javac compiler; com.sun.tools.javac.Main is not on the classpath. Perhaps JAVA_HOME does not point to the JDK. It is currently set to "/usr/lib/jvm/java-6-sun-1.6.0.03/jre" at AntBuilderProblem.run(AntBuilderProblem.groovy:1) at AntBuilderProblem.main(AntBuilderProblem.groovy)
        Hide
        Russel Winder added a comment -

        OK, I have doen the experiment: I downloaded Groovy RC-1 and used that and everything is fine. Groovy RC-2 and Subversion head have the problem. This is definitely not a Gant or Ant problem per se since they were not changed. Thus something has changed between RC-1 and RC-2 which means that in effect Groovy is broken.

        I think the AntBuilder code acts as a test. I will turn this into a Groovy unit test and add it in. This will of course mean that the Groovy tests will break.

        Show
        Russel Winder added a comment - OK, I have doen the experiment: I downloaded Groovy RC-1 and used that and everything is fine. Groovy RC-2 and Subversion head have the problem. This is definitely not a Gant or Ant problem per se since they were not changed. Thus something has changed between RC-1 and RC-2 which means that in effect Groovy is broken. I think the AntBuilder code acts as a test. I will turn this into a Groovy unit test and add it in. This will of course mean that the Groovy tests will break.
        Hide
        Russel Winder added a comment -
        > more GROOVY_2258.groovy
        #! /usr/bin/env groovy

        new AntBuilder ( ).javac ( srcdir : '.' , destdir : '/tmp' )

        > which groovy
        /home/users/russel/lib/Java/groovy/bin/groovy
        > groovy -v
        Groovy Version: 1.1-final-SNAPSHOT JVM: 1.6.0_03-b05
        > groovy GROOVY_2258.groovy
        [javac] Compiling 17 source files to /tmp
        Caught: : Unable to find a javac compiler;
        com.sun.tools.javac.Main is not on the classpath.
        Perhaps JAVA_HOME does not point to the JDK.
        It is currently set to "/usr/lib/jvm/java-6-sun-1.6.0.03/jre"
        at GROOVY_2258.run(GROOVY_2258.groovy:3)
        at GROOVY_2258.main(GROOVY_2258.groovy)
        > GROOVY_HOME=/sparedisk/russel/groovy-1.1-rc-1/target/install /sparedisk/russel/groovy-1.1-rc-1/target/install/bin/groovy GROOVY_2258.groovy
        [javac] Compiling 17 source files to /tmp
        /home/users/russel/Progs/OddsByLanguage/Groovy/GROOVY-917/X.java:1: duplicate class: X
        public class X {
        ^
        /home/users/russel/Progs/OddsByLanguage/Groovy/IanDarwin/wc.java:7: class WC is public, should be declared in a file named WC.java
        public class WC {
        ^
        2 errors
        Caught: : Compile failed; see the compiler error output for details.
        at GROOVY_2258.run(GROOVY_2258.groovy:3)
        at GROOVY_2258.main(GROOVY_2258.groovy)
        >
        Show
        Russel Winder added a comment - > more GROOVY_2258.groovy #! /usr/bin/env groovy new AntBuilder ( ).javac ( srcdir : '.' , destdir : '/tmp' ) > which groovy /home/users/russel/lib/Java/groovy/bin/groovy > groovy -v Groovy Version: 1.1-final-SNAPSHOT JVM: 1.6.0_03-b05 > groovy GROOVY_2258.groovy [javac] Compiling 17 source files to /tmp Caught: : Unable to find a javac compiler; com.sun.tools.javac.Main is not on the classpath. Perhaps JAVA_HOME does not point to the JDK. It is currently set to "/usr/lib/jvm/java-6-sun-1.6.0.03/jre" at GROOVY_2258.run(GROOVY_2258.groovy:3) at GROOVY_2258.main(GROOVY_2258.groovy) > GROOVY_HOME=/sparedisk/russel/groovy-1.1-rc-1/target/install /sparedisk/russel/groovy-1.1-rc-1/target/install/bin/groovy GROOVY_2258.groovy [javac] Compiling 17 source files to /tmp /home/users/russel/Progs/OddsByLanguage/Groovy/ GROOVY-917 /X.java:1: duplicate class: X public class X { ^ /home/users/russel/Progs/OddsByLanguage/Groovy/IanDarwin/wc.java:7: class WC is public, should be declared in a file named WC.java public class WC { ^ 2 errors Caught: : Compile failed; see the compiler error output for details. at GROOVY_2258.run(GROOVY_2258.groovy:3) at GROOVY_2258.main(GROOVY_2258.groovy) >
        Hide
        Jochen Theodorou added a comment -

        the change I can think of is that the tools.jar is no longer loaded by default through Groovy. And I guess since it is not loaded through Groovy, ant tries to find it by itself and does that wrong. I still really suspect that ant is doing something wrong here. adding tools.jar would be a workaround that you could try. If it works then, then I really think it is the fault of Ant, if not, then it is something inside Groovy I guess... something I have no ideas of what it could be.

        Show
        Jochen Theodorou added a comment - the change I can think of is that the tools.jar is no longer loaded by default through Groovy. And I guess since it is not loaded through Groovy, ant tries to find it by itself and does that wrong. I still really suspect that ant is doing something wrong here. adding tools.jar would be a workaround that you could try. If it works then, then I really think it is the fault of Ant, if not, then it is something inside Groovy I guess... something I have no ideas of what it could be.
        Hide
        Russel Winder added a comment - - edited

        As observed by Jochen Theodorou, the thing that is causing the difference is the presence or absence of the line:

        load $

        {tools.jar}

        in $GROOVY_HOME/conf/groovy-starter.conf. With the line AntBuilder works fine but Mac OS X won't work because Apple have merged rt.jar and tools.jar into a single classes.jar in the Mac OS X version of Java (for some incomprehensible reason). Without the line, Mac OS X is fine but AntBuilder now has a serious problem, it fails to fins any class in tools.jar.

        We therefore have a dilema, Groovy is either broken on Mac OS X or has a broken AntBuilder.

        Show
        Russel Winder added a comment - - edited As observed by Jochen Theodorou, the thing that is causing the difference is the presence or absence of the line: load $ {tools.jar} in $GROOVY_HOME/conf/groovy-starter.conf. With the line AntBuilder works fine but Mac OS X won't work because Apple have merged rt.jar and tools.jar into a single classes.jar in the Mac OS X version of Java (for some incomprehensible reason). Without the line, Mac OS X is fine but AntBuilder now has a serious problem, it fails to fins any class in tools.jar. We therefore have a dilema, Groovy is either broken on Mac OS X or has a broken AntBuilder.
        Hide
        Jochen Theodorou added a comment -

        I took a look at the ant source and found this line:

            private static final String JAVA_HOME = System.getProperty("java.home");

        which makes me ask myself who is setting this property... running a java program on my windows machine this shows me: "C:\Programme\JavaSoft\sdk\jre" and then it is no wonder it gets a problem, because that is the JRE and not the JDK part. I confirmed this with my linux machine.. it is pointing to "/usr/lib/j2sdk1.5-sun/jre" there and that differs from my JAVA_HOME which is set to "/usr/lib/j2sdk1.5-sun"

        I must say I think the ANT message is extremly misleading, because even though it is speaking of JAVA_HOME, it means the property java.home and that property is set by the VM to the JRE and not the JDK. No wonder Ant will not find the javac binary, because in that directory and its subdirectories, there is no javac command. So in my eyes ant is broken here. I guess when running ant from the command line, something in ant-utils or such will correct the path.

        The question is now how we react to this. I mean it is clear, that the javac class won't be found, if it is not on the classpath, which will happen if we don't include the tools.jar. Or should the user have to do that? Russel, what do you suggest?

        Show
        Jochen Theodorou added a comment - I took a look at the ant source and found this line: private static final String JAVA_HOME = System .getProperty( "java.home" ); which makes me ask myself who is setting this property... running a java program on my windows machine this shows me: "C:\Programme\JavaSoft\sdk\jre" and then it is no wonder it gets a problem, because that is the JRE and not the JDK part. I confirmed this with my linux machine.. it is pointing to "/usr/lib/j2sdk1.5-sun/jre" there and that differs from my JAVA_HOME which is set to "/usr/lib/j2sdk1.5-sun" I must say I think the ANT message is extremly misleading, because even though it is speaking of JAVA_HOME, it means the property java.home and that property is set by the VM to the JRE and not the JDK. No wonder Ant will not find the javac binary, because in that directory and its subdirectories, there is no javac command. So in my eyes ant is broken here. I guess when running ant from the command line, something in ant-utils or such will correct the path. The question is now how we react to this. I mean it is clear, that the javac class won't be found, if it is not on the classpath, which will happen if we don't include the tools.jar. Or should the user have to do that? Russel, what do you suggest?
        Hide
        Russel Winder added a comment -

        Jochen, well spotted!

        println ( System.properties.'java.home' )
        

        prints the path to the JRE for me as well. This is of course not surprising and exactly as it should be since this is the path to the JVM, not to the JDK.

        I think it is clear that the Ant error message is completely misleading. I have added a bug report in the Ant Bugzilla (43794).

        I think we have to find out what Ant does internally to allow the javac task to run, so that we know how Ant gets round this problem. Currently I am assuing they define their own class loader and it looks in all the right places, including tools.jar on all systems other than Mac OS X.

        I think that maybe Groovy should check to see if it is running from a JRE or from a JDK with embedded JRE, and in the latter case add tools.jar to the classpath. This then ensures people running only on a JRE can run Groovy (but at the expense of not being able to do some things such as run the Ant javac task) whilst people using a JDK get everything and no surprises. This also gets round the Mac OS X problem since classes.jar is already on the classpath.

        Show
        Russel Winder added a comment - Jochen, well spotted! println ( System .properties.'java.home' ) prints the path to the JRE for me as well. This is of course not surprising and exactly as it should be since this is the path to the JVM, not to the JDK. I think it is clear that the Ant error message is completely misleading. I have added a bug report in the Ant Bugzilla (43794). I think we have to find out what Ant does internally to allow the javac task to run, so that we know how Ant gets round this problem. Currently I am assuing they define their own class loader and it looks in all the right places, including tools.jar on all systems other than Mac OS X. I think that maybe Groovy should check to see if it is running from a JRE or from a JDK with embedded JRE, and in the latter case add tools.jar to the classpath. This then ensures people running only on a JRE can run Groovy (but at the expense of not being able to do some things such as run the Ant javac task) whilst people using a JDK get everything and no surprises. This also gets round the Mac OS X problem since classes.jar is already on the classpath.
        Hide
        Jochen Theodorou added a comment -

        As said on the list, the solution seems to be for me to use a slightly different property syntax in the conf file. for example $

        {x?}

        instead of $

        {x}, where the ? indicates that the property might not be set. then we can modify the tools.jar line to "load ${tools.jar?}". an alternative syntax wold be $?{x}

        or simply ?

        {x}. Or we could go the other way and say an error should be thrown if a property does not exist, but assign this a another syntax like !{x}

        and say that $

        {x}

        will handle non existing properties.

        Show
        Jochen Theodorou added a comment - As said on the list, the solution seems to be for me to use a slightly different property syntax in the conf file. for example $ {x?} instead of $ {x}, where the ? indicates that the property might not be set. then we can modify the tools.jar line to "load ${tools.jar?}". an alternative syntax wold be $?{x} or simply ? {x}. Or we could go the other way and say an error should be thrown if a property does not exist, but assign this a another syntax like !{x} and say that $ {x} will handle non existing properties.
        Hide
        Jochen Theodorou added a comment -

        ok, I changed the conf file and the class using that file as config. $

        {x} now defines a not required property. If x is not defined, then the whole load instruction for this will be ignored. This means a
        load ${tools.jar}
        

        will be ignored if tools.jar is not set. To get the old version you need to use $!{x}

        , which will then throw an error. This should fix the problem since with this the tools.jar will be on the classpath per default again and then ANT should be able to find the javac class again and does not try to find the external javac compiler, which seems not to work in many configurations.

        so I close this as fixed for now. Would be nice of you to test it and see if it is really fixed Russel.

        Show
        Jochen Theodorou added a comment - ok, I changed the conf file and the class using that file as config. $ {x} now defines a not required property. If x is not defined, then the whole load instruction for this will be ignored. This means a load ${tools.jar} will be ignored if tools.jar is not set. To get the old version you need to use $!{x} , which will then throw an error. This should fix the problem since with this the tools.jar will be on the classpath per default again and then ANT should be able to find the javac class again and does not try to find the external javac compiler, which seems not to work in many configurations. so I close this as fixed for now. Would be nice of you to test it and see if it is really fixed Russel.

          People

          • Assignee:
            Jochen Theodorou
            Reporter:
            Russel Winder
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development