It looks like, even tough DAS has the proper stax dependency, it is
only working if I make SDO stax dependency not optional. I changed the
sdo\impl\pom.xml to have :

       <dependency>
           <groupId>stax</groupId>
           <artifactId>stax-api</artifactId>
           <version>1.0.1</version>
       </dependency>

Thoughts on why this changed again ?

On 7/11/07, Luciano Resende <[EMAIL PROTECTED]> wrote:
Kelvin, trying to build DAS I'm getting the following exception :

[INFO] ------------------------------------------------------------------------
[INFO] javax/xml/stream/XMLStreamException
[INFO] ------------------------------------------------------------------------
[INFO] Trace
java.lang.NoClassDefFoundError: javax/xml/stream/XMLStreamException
        at 
org.apache.tuscany.sdo.helper.HelperContextImpl.<init>(HelperContextImpl.java:64)
        at 
org.apache.tuscany.sdo.generate.XSD2JavaGenerator.generateFromXMLSchema(XSD2JavaGenerator.java:171)
        at 
org.apache.tuscany.sdo.generate.XSD2JavaGenerator.generateFromXMLSchema(XSD2JavaGenerator.java:155)
        at 
org.apache.tuscany.sdo.plugin.GeneratorMojo.execute(GeneratorMojo.java:270)
        at 
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
        at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
        at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
        at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459)
        at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
        at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
        at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
        at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
        at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
        at org.apache.maven.cli.MavenCli.main(MavenCli.java:280)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
        at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
        at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
        at org.codehaus.classworlds.Launcher.main(Launcher.java:375)


Are these related to the EMF dependency issues ?


On 7/11/07, Luciano Resende <[EMAIL PROTECTED]> wrote:
> In the meantime, as a workaround, what''s the right place to get the
> correct file ?
>
> On 7/11/07, kelvin goodson <[EMAIL PROTECTED]> wrote:
> > I've been taking a proper look at this issue,  as we are just papering over
> > the cracks here by passing around private jars.  I spoke to someone at
> > eclipse who said that the size of the jar in the 2.2.3 distribution on the
> > eclipse site is 188KB.  However, I have a 2.2.3 zip file distribution
> > stashed on my hard drive that has the codegen-ecore file at 756KB.  If I
> > switch back to the 188KB version I get 260 compile errors in the sdo-tools
> > project, due to things like "GenClass can not be resolved to a type".
> >
> > I just, in the course of typing this note,  tried listing the contents of
> > the 188KB file,  and for the first time got an indication that the file is
> > in some way corrupt, so I will go back to the eclipse guy and see what he
> > can do  ...
> >
> > C:\Documents and
> > 
Settings\Administrator\.m2\repository\org\eclipse\emf\codegen-ecore\2.2.3>jar
> > -tvf codegen-ecore-2.2.3
> > jar > 188KBcontents.txt
> > java.io.EOFException: Unexpected end of ZLIB input stream
> >         at java.util.zip.InflaterInputStream.fill(InflaterInputStream.java
> > :241)
> >         at java.util.zip.InflaterInputStream.read(InflaterInputStream.java
> > :159)
> >         at java.util.zip.ZipInputStream.read(ZipInputStream.java:155)
> >         at java.util.zip.ZipInputStream.closeEntry(ZipInputStream.java:107)
> >         at sun.tools.jar.Main.list(Main.java:782)
> >         at sun.tools.jar.Main.run(Main.java:228)
> >         at sun.tools.jar.Main.main(Main.java:942)
> >
> > Regards, Kelvin.
> >
> >
> > On 06/07/07, Simon Laws <[EMAIL PROTECTED]> wrote:
> > >
> > >
> > >
> > > On 7/6/07, kelvin goodson <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Simon,
> > > >
> > > > the codegen-ecore2.2.3.jar file in that repository is much smaller than
> > > > the
> > > > one in my local repository (188KB versus 756KB).  Both can be inspected
> > > > by
> > > > jar -tvf,  so it wouldn't appear to be a file truncation problem.  I
> > > > have
> > > > sent you my version via direct email.  Please let me know if this fixes
> > > > your
> > > > problem.  I will pursue an eclipse contact to try to get this fixed up.
> > > >
> > > > Regards, Kelvin.
> > > >
> > > > On 06/07/07, Simon Laws < [EMAIL PROTECTED]> wrote:
> > > > >
> > > > > Now that the server problems seem to be solved I've again been trying
> > > > to
> > > > > build DAS but have SDO problems. When maven comes to downloading emf
> > > > > dependencies it reports checksum failures (not sure if this is
> > > > > significant)...
> > > > >
> > > > > [INFO]
> > > > >
> > > > 
-------------------------------------------------------------------------
> > > > > ---
> > > > > [INFO] Building Tuscany SDO Tools
> > > > > [INFO]    task-segment: [install]
> > > > > [INFO]
> > > > >
> > > > 
-------------------------------------------------------------------------
> > > > > ---
> > > > > [INFO] [resources:resources]
> > > > > [INFO] Using default encoding to copy filtered resources.
> > > > > Downloading:
> > > > > http://people.apache.org/repo/m2-incubating-repository//org/eclipse
> > > > > /emf/codegen/2.2.3/codegen-2.2.3.pom
> > > > > Downloading:
> > > > > http://ftp.ussg.iu.edu/eclipse/modeling/emf/emf/maven2//org/eclipse
> > > > > /emf/codegen/2.2.3/codegen-2.2.3.pom
> > > > > 153b downloaded
> > > > > [WARNING] *** CHECKSUM FAILED - Error retrieving checksum file for
> > > > > org/eclipse/e
> > > > > mf/codegen/2.2.3/codegen-2.2.3.pom - IGNORING
> > > > >
> > > > >
> > > > > It then reports problems with the build..
> > > > >
> > > > > [INFO] Compilation failure
> > > > >
> > > > > error: error reading C:\Documents and
> > > > > Settings\simon\.m2\repository\org\eclipse\
> > > > > emf\codegen-ecore\2.2.3\codegen-ecore-2.2.3.jar; Error opening zip
> > > > file
> > > > > C:\Docum
> > > > > ents and
> > > > >
> > > > Settings\simon\.m2\repository\org\eclipse\emf\codegen-ecore\2.2.3\codeg
> > > > > en-ecore-2.2.3.jar
> > > > >
> > > > >
> > > > 
C:\simon\Projects\Tuscany\java\java-head\sdo\tools\src\main\java\org\apache\tusc
> > > >
> > > > > any\sdo\generate\adapter\SDOGenClassGeneratorAdapter.java:[22,47]
> > > > package
> > > > > org.ec
> > > > > lipse.emf.codegen.ecore.generator does not exist
> > > > >
> > > > >
> > > > > So in particular codegen-ecore-2.2.3.jar seems to be duff.  Anyone
> > > > else
> > > > > seeing this or is it just me?
> > > > >
> > > > > Simon
> > > > >
> > > >
> > > Thanks for the jar. It fixed my problem so there is something strange with
> > > that file in the repo.
> > >
> > > Simon
> > >
> >
>
>
> --
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende
> http://lresende.blogspot.com/
>


--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/



--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to