integration tests use Runtime constructs, causes dependency problems and classpath problems

What steps will reproduce the problem?
1. RunTests.java spawns child processes to perform indexing at lines 126 and 
134. 
2. These processes do not have the same access to classpath and other command 
line arguments.
3. Sometimes the classpath will be borked and the file cannot be found, 
sometimes the debugger created at runtime will not be started for the child 
process, etc.

What is the expected output? What do you see instead?
I'd like to have the child process start with the same environment and 
arguments as the parent. I'd also like the compiler to check the dependency at 
compile time and not at runtime.

Please use labels and text to provide additional information.
• I realize that the goal is to run these programs in a separate process to 
better simulate actual use of the programs, so any solution should account for 
this design goal.
• I ran the test suite using jdb to find a bug. The child process didn't 
start under jdb, but rather under java (just like it is told to do in 
RunTests). It would be nice if it ran using the same program as specified from 
ant. I'm not sure how to get this behavior yet, but I think it could be done.
• My CLASSPATH didn't include the lucene demo because it wasn't necessary for 
compiling the test. Then the hardcoded call to a program found inside of the 
lucene demo raised a ClassNotFound exception at runtime. I think a better 
practice would be to import the target file within the test suite, which 
necessitates a valid classpath at compile time. My favored approach would be to 
have the method that starts a process take an argument of type Class, and then 
use that Class to create the program path. I'll have an implementation for this 
idea soon.
• The hardcoded call to Runtime.exec(String) doesn't pass a "-classpath 
<path>" argument, or any other arguments. I'd like to preserve the original 
arguments and maybe even environment of the parent. It looks like 
java.lang.ProcessBuilder might keep the solution tidy. I'll investigate this 
too.

Original issue reported on code.google.com by ThomasCR...@gmail.com on 22 Nov 2010 at 9:38

seunginah / semanticvectors

integration tests use Runtime constructs, causes dependency problems and classpath problems #31