Dan,
I think something like this would be a bit more robust:
static boolean compileJavaSrc(Path classPath, Path srcPath, String dest) {
String[] srcList = srcPath.list();
List<String> javacCommand = new ArrayList<String>();
javacCommand.add("javac");
if(classPath != null && classPath.size() > 0){
javacCommand.add("-classpath");
javacCommand.add(classPath.toString());
}
javacCommand.add("-d");
javacCommand.add(dest.toString());
javacCommand.add("-target");
javacCommand.add("1.5");
for (int i = 0; i < srcList.length; i++) {
javacCommand.add(srcList[i]);
}
org.apache.cxf.tools.util.Compiler javaCompiler
= new org.apache.cxf.tools.util.Compiler();
return javaCompiler.internalCompile(javacCommand.toArray(new
String[javacCommand.size()]), javacCommand.size());
}
However, I don't think most users will get too far past the javac error
before they run into this:
[java] C:/DOCUME~1/USER/LOCALS~1/Temp/org.apache.cxf.endpoint.dynamic.
[EMAIL PROTECTED]/com/terraserver_usa/terraserver/A
reaBoundingBox.java:4: package javax.xml.bind.annotation does not exist
[java] import javax.xml.bind.annotation.XmlAccessType;
...
I'm finding that the problem stems from using the AntClassLoader. Since
this classloader does not extend URLClassLoader, the DynamicClientFactory
doesn't load the classes in its classpath (see the setupClasspath method).
The DynamicClientFactory could probably be revised to allow classloaders
that don't extend URLClassloader.
As a workaround, users have two options:
1. Don't use Ant to run the app. Make a script that constructs the
classpath and runs the app.
2. If using a classloader that does extend URLClassLoader (i.e.
GroovyClassLoader), make sure that this classloader has the entire classpath
instead of deferring to its parent.
Thanks,
Peter
--
View this message in context:
http://www.nabble.com/Javac---invalid-flag-tp19162293p19181757.html
Sent from the cxf-user mailing list archive at Nabble.com.
