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
