This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
In some ways this is an RFE, but I decided to make it a bug because the implementation we are using doesn't let you do something you can do from the command line when starting Netbeans. The problem is that XTest pulls the JDK from JAVA_HOME but doesn't let you override it via properties. I have worked around this by creating a property and removing the jdkhome property from two places in module_harness.xml. If you try to pass in the JDK to the command line it doesn't work because XTest has already added this command line argument and their is not a command line prefix option...which probably is a good thing. What we are doing is running XTest and compiling our infrastructure using a single standard JDK. However for certification testing we need to run the IDE using other JDKs. We don't want to compile infrastructure and run XTest using the other jdks. As part of implementing this support, some consideration might be given to how system is presented in XTest output and what it means to report XTest results when different JDKs are used for different test runs. For us we will actually always be running XTest using the same jdk, so the system summary information is probably still relevant.
Allowing XTest to run tests in a specified JDK is quite easy. Unfortunately there is a problem with this when running in Ant < 1.5 (1.4.1 is the officially used Ant for building ...). Ant 1.4 does not easily allow to use a different version of javac than the one from JDK which is used to run XTest. The other problem is how to include information about jdk version used for the test run. Currently, XTest gives you system information for the whole report (which can contain several test runs), but more appropriate will be to give JDK information for each test run, because each time it can be different.
Just in the case you don't know it - currently you can already supply the java home to XTest. Just use 'jdkhome' ant variable (e.g. 'ant runtests -Djdkhome=/space/jdk1.3.1_01'). Unfortunately this feature has currently two (well three :-() problems: - only IDE tests use the supplied jdkhome, code tests use exactly the same jdk as the build script is run in (i.e. the one taken by Ant for execution). - the same thing applies to the resulting report - system info available in xtest results report will give you java version taken from ant, not from jdkhome - finally, because system info is global for the whole report (not for a single test run), when changing the jdkhome between test runs, the information about java version is not correct. I should be able to fix the first problem quite easilly - I basically need to enhance the JUnitTestRunnerTask to use the supplied jdkhome. The second problem is not that easy, because the system info is currently taken from system variables. I will need to execute code gathering the system code in a specified JDK, which will need a major rewrite of the current code. Unfortunately, the third problem cannot be easily fixed at all, because it will require to change the DTD of the xtest results report and this has direct effect on all the additional tools working with the report (e.g. PES and central database). Anyway I will think about this problem more, since there might be some backward compatible solution.
Issue #1 fixed. Now when jdkhome property is specified, code tests use java from this directory for run.
Fixing the first item sounds good. I think it is ok if the report indicates what Java the report is running under. It seems like a new report format with a column for JDK would be required. Perhaps JDK is written to XML files which then produce report columns. Clearly this would be new work effort. What we have been doing here is simply verifying the correct JDK is being used by looking at the IDE log. We "patched" XTest so we could pass in our own jdkhome. The patch simply removing the existing jdkhome from the IDE startup command line, so we can add then it to the end of the command line using the existing xtest capabilities.