You're right, if I stay with SDO1 for now then there's no need to regen the existing model, so I'll leave this alone for now.
Out of interest - After Franks reply I did get this to work by changing the schemaLocation to have the absolute file location of the sca-core.xsd, is there a way to define this relative to the enclosing schema? Also the code that resulted didn't have any methods relating to the port element in the WS binding schema, don't know if thats a bug or I was doing something wrong. ...ant On 2/15/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > Frank Budinsky wrote: > > Hi ant, > > > > It looks to me like the generator may be failing because this imported > > schema is not available (is failing to resolve): > > > > <import schemaLocation="sca-core.xsd" > > namespace="http://www.osoa.org/xmlns/sca/0.9"/> > > > > (I agree that the error checking/messages need improvement.) > > > > Is sca-core.xsd available in your environment? > > > > Actually, a more general question is has sca-core.xsd been moved to > > (generated with) SDO 2 yet? If not, this won't work yet anyway. > > > > Frank. > > > > > > ant elder <[EMAIL PROTECTED]> wrote on 02/15/2006 08:14:46 AM: > > > > > >> Should I be able to use the Tuscany SDO JavaGenerator to gen all the > SDO > >> stuff for the new Axis2 based WS binding? > >> > >> Running it with the following args gets a NPE: > >> > >> -targetDirectory \temp\sdoGen > >> C:\SCA\SCA6\sca\binding.axis\src\main\resources\model\sca- > >> binding-webservice.xsd > >> > >> Exception in thread "main" java.lang.NullPointerException > >> at > >> > >> > > > org.eclipse.emf.codegen.ecore.genmodel.impl.GenPackageImpl$DependencyHelper > > > >> .<init>(GenPackageImpl.java:1859) > >> at > >> > > org.eclipse.emf.codegen.ecore.genmodel.impl.GenPackageImpl.generate( > > > >> GenPackageImpl.java:2385) > >> at > >> > > org.eclipse.emf.codegen.ecore.genmodel.impl.GenModelImpl.generate( > > > >> GenModelImpl.java:1932) > >> at org.eclipse.emf.codegen.ecore.genmodel.impl.GenBaseImpl.gen( > >> GenBaseImpl.java:355) > >> at > >> > > org.apache.tuscany.sdo.generate.JavaGenerator.generateFromGenModel( > > > >> JavaGenerator.java:293) > >> at > >> > > org.apache.tuscany.sdo.generate.JavaGenerator.generateFromEPackage( > > > >> JavaGenerator.java:278) > >> at > >> > > org.apache.tuscany.sdo.generate.JavaGenerator.generateFromXMLSchema( > > > >> JavaGenerator.java:255) > >> at > >> > > org.apache.tuscany.sdo.generate.JavaGenerator.main(JavaGenerator.java > > > >> :222) > >> > >> ...ant > >> > > > > > > > Ant, > > The core assembly model has not moved to SDO2 yet, I'm in the process of > changing the assembly models to be a combination of SDO2 models (for XML > deserialization) and pure POJO models (logical models used to configure > the runtime), building on the approach introduced by Jim in > o.a.t.model.assembly.pojo. This is quite a bit of work but I should be > ready to commit this new set of models later this week. I'm taking care > of the core assembly model, the java container model and the web service > assembly model (I want to handle these two at least to flesh out any > model extensibility issues raised by component types and binding types). > I'll let others port their own models (e.g. the container.js model) later. > > In the meantime you can continue to use the existing > o.a.t.binding.axis.assembly model, which is an SDO1 model. If you want > to create another binding model you'll have to generate an SDO1 model > like I think you did for the container.js component implementation type > model, but I'm not even sure you need to do this here... With the axis2 > integration we're not introducing a new web service binding model, we're > just porting our implementation of the existing web service binding to > Axis 2, so I'm not sure why you would need to regenerate a new binding > model, is there anything missing in o.a.t.binding.axis.assembly.model? > are you introducing any changes to the definition of the web service > binding and the corresponding XSD? > > -- > Jean-Sebastien > >
