Glen, I'm not really sure what the "right" answer is. Since the wsdl2java will dynamically load various things (like xjc-dv and the databindings and such), you may need to add extra things to get them resolved.
In general, if I'm debugging wsdl2java things, I tend to temporarily add a fake test to the bottom of org.apache.cxf.tools.wsdlto.jaxws.CodeGenTest (in the wsdlto-test module) and debug it that way. Dan On Mon April 20 2009 4:12:52 am Glen Mazza wrote: > Hello, > > I'm trying to run trunk's WSDLToJava.java in debug mode in Eclipse. I've > imported the CXF project as described on our Eclipse page[1], in > particular, these steps here to import all the CXF subprojects: > > # Select "Existing Projects into Workspace" and hit Next > # Select root directory: enter the path to your trunk directory and hit > Next. > # Select all the subprojects and hit Finish. Eclipse will import and > rebuild all the subprojects selected. This will take a while. > > However, trying to debug WSDLToJava.java from the Eclipse IDE raised errors > that certain subprojects referenced were missing--I needed to manually add > them into the project: cxf-common-schemas, cxf-common-utilities, and > cxf-xjc-dv. Question: Does this point to an error with our Eclipse build > instructions and/or CXF's main (root) pom file, namely that it is not > referencing these subprojects so that when we select all the subprojects as > instructed above we end up missing these subprojects? Or, was it never > really intended for these three subprojects to be included in the "all the > subprojects selected" above because they are already available in > higher-level subprojects (i.e., cxf-common). > > The Eclipse instructions are meant for developing CXF, not debugging > WSDLToJava, so that might account for my need to manually import these > additional subprojects. Just want to make sure, though, I'm not doing > anything wrong that would cause me to need to do these additional imports. > > Thanks, > Glen > > [1] http://cxf.apache.org/setting-up-eclipse.html -- Daniel Kulp [email protected] http://www.dankulp.com/blog
