Ant version reported by the Jazz Build Engine is wrong
Hi Folks,
This is a follow-up to an earlier unanswered post concerning the JBE. I'm running the RTC 3.0.1 build engine and am having difficulty getting ant to correctly recognize junit 4 tests. After trying many things I decided to check the ant version. Supposedly, the build engine for RTC 3.0.1 runs ant 1.7.1 which does support junit 4. However, when I add the ant option "-version" to my ant configuration for the build it consistently reports ant version 1.6.5 -- even when I change the ant home to point to a 1.8 ant installation. I can't tell whether it's simply reporting it incorrectly or actually using the wrong ant version. Or perhaps I've been misinformed about how this is all supposed to work. Hard to find documentation at this level of detail. Whatever the case, it's strange. This has been going on for more than a week now so any help would be greatly appreciated. Here is the output when I run with the "-version" option:
|
6 answers
Hi Tamir,
We definitely ship Ant 1.7.1 as part of the Build System Toolkit. Try the following: - cd to <build system toolkit install dir>\jazz\buildsystem\buildengine\eclipse\plugins\org.apache.ant_1.7.1.v20090120-1145\lib - run: java -jar ant-launcher.jar -version I get: Apache Ant version 1.7.1 compiled on June 27 2008 This is the behaviour you should get if the Ant Home field in the build definition is left blank. If it's not blank, it should use the version pointed to (you should point it to the parent directory containing lib, not lib itself). You could try the version command in that other location too. Also (and please excuse me for stating the obvious), be sure to test it on the build machine where the build actually runs, not your development machine. |
Also, check for any CLASSPATH environment variable on the build machine, and clear it if set. Be sure to do this for the global env var settings, not just for the current shell:
http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/environment_variables.mspx?mfr=true The CLASSPATH env var shouldn't matter even if set. The -classpath command line arg (that JBE uses when launching Ant) should take precedence. Also, which version of Java are you using to run JBE? Add -verbose to the JBE command line args to get it to print out this info. We recommend using the JDK that ships with the RTC Eclipse client (or server). |
Also, check for any CLASSPATH environment variable on the build machine, and clear it if set. Be sure to do this for the global env var settings, not just for the current shell: Hi Nick, Thanks for the help. I checked the ant version as you indicated in your previous post and it does give me 1.7.1 -- same as you. I do have a CLASSPATH variable set with various paths but I can't clear it completely because it is being used by other applications. Was there something in particular that I should look out for? For Java I'm using IBM's JDK 1.6.0-26. I've installed RTC using the p2 install into an eclipse helios jee installation. As far as I can tell in that configuration there is no java.exe to refer to. Is there? When I run the JBE with "-verbose" I get: Java Version: Anything else I should try? Thanks, Tim |
That Java version is different than the one you said you were using, but it should work OK. Try running JBE with an explicit -vm command line arg pointing to the java executable in your IBM JDK install.
https://jazz.net/wiki/bin/view/Main/BuildFAQ#WhichJDK |
That Java version is different than the one you said you were using, but it should work OK. Try running JBE with an explicit -vm command line arg pointing to the java executable in your IBM JDK install. Hi Nick, Well, that did it. It works when I explicitly point to the 1.6 JDK. I can't say I understand why the version it was finding wouldn't work but I'm happy it's working now. Thanks! Tim |
The only thing I can think of is that there's some environment variable or other configuration option that's causing the Sun/Oracle VM to resolve classes for Ant in some other location than what we specify for the classpath (as a command line arg).
Maybe there's a setting for the boot class path, which would take priority over the regular class path setting. |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.