Home » Modeling » EMF » Interoperation of different EMF versions?
|
| Re: Interoperation of different EMF versions? [message #418777 is a reply to message #418775] |
Tue, 29 April 2008 13:27   |
 Ed Merks
Messages: 33218
Registered: July 2009 |
Senior Member |
|
|
Tobias,
Comments below.
Tobias wrote:
> Hello,
>
> I am currently building a model transformation from my own metamodel
> to a metamodel from an imported JAR. Both metamodels are implemented
> in EMF, however the model from the jar has been created using EMF 2.2
> (as far as I understood the responsible developer this was necessary
> due to some problems that otherwise occured with OWL...).
>
> While there are no interoperability problems with the transformation
> itself, there are problems when accessing the XXXPackage class of the
> metamodel implemented in EMF 2.2, which ultimatively prevents me from
> writing the results of the transformation to XML (and causes problems
> in some other places, too).
If you want your model to work with EMF 2.2, you'd need to ensure that
you generate with Java 1.4 compatibility and you need to avoid the use
of generics in your model.. That should produce code that will work
with the 2.2 runtime.
>
> So my question is: Is there a general problem with using an EMF-2.2
> Package-Class together with EMF-2.3, and is there a way to fix it/work
> around it?
It should be fine to use 2.2 stuff in a 2.3 runtime, but the opposite is
tricker. Can you be more specific about the problems you're seeing?
>
> Regards,
> Tobias
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Interoperation of different EMF versions? [message #418783 is a reply to message #418777] |
Tue, 29 April 2008 14:50 |
Tobias
Messages: 18
Registered: July 2009 |
Junior Member |
|
|
Ed Merks schrieb:
> Tobias wrote:
>> While there are no interoperability problems with the transformation
>> itself, there are problems when accessing the XXXPackage class of the
>> metamodel implemented in EMF 2.2, which ultimatively prevents me from
>> writing the results of the transformation to XML (and causes problems
>> in some other places, too).
> If you want your model to work with EMF 2.2, you'd need to ensure that
> you generate with Java 1.4 compatibility and you need to avoid the use
> of generics in your model.. That should produce code that will work
> with the 2.2 runtime.
Hello Ed,
Unfortunately, I do not think that it would be feasible to downgrade my
tool to EMF 2.2 to ensure compatibility with the JARs.
The original project of the imported JAR is using ecore- common- and
ecore-xmi in version 2.2.0, while my GMF-Editor is using version 2.3.2.
When instantiating the XXXPackage in a "plain old" JavaApplication using
the 2.2.0 JARs everything works fine, but when running an Eclipse
runtime I have to use 2.3.2 for my other models and tools, which are
based on GMF 2.0
>> So my question is: Is there a general problem with using an EMF-2.2
>> Package-Class together with EMF-2.3, and is there a way to fix it/work
>> around it?
> It should be fine to use 2.2 stuff in a 2.3 runtime, but the opposite is
> tricker. Can you be more specific about the problems you're seeing?
Everytime I try to get an instance of the Package class, i.e.
XXXPackage.eINSTANCE, I get a ClassDefNotFound exception "Could not
initialize class x.x.x.XXXPackage$Literals". Of course the same applies
when invoking various introspective methods using the package, e.g.
eObject.eContents(), where eObject is an Object of the imported
metamodel. As I said, the imported JAR was created using 2.2.0 while the
application it has to be used in requires 2.3.2.
It would be great if you could help.
Regards,
Tobias
|
|
|
| Re: Interoperation of different EMF versions? [message #418784 is a reply to message #418783] |
Tue, 29 April 2008 15:03 |
Ed Merks
Messages: 33218
Registered: July 2009 |
Senior Member |
|
|
Tobias,
Comments below.
Tobias wrote:
> Ed Merks schrieb:
>> Tobias wrote:
>>> While there are no interoperability problems with the transformation
>>> itself, there are problems when accessing the XXXPackage class of
>>> the metamodel implemented in EMF 2.2, which ultimatively prevents me
>>> from writing the results of the transformation to XML (and causes
>>> problems in some other places, too).
>> If you want your model to work with EMF 2.2, you'd need to ensure
>> that you generate with Java 1.4 compatibility and you need to avoid
>> the use of generics in your model.. That should produce code that
>> will work with the 2.2 runtime.
>
> Hello Ed,
>
> Unfortunately, I do not think that it would be feasible to downgrade
> my tool to EMF 2.2 to ensure compatibility with the JARs.
I was only suggesting you target the 2.2 runtime (by targeting Java 1.4)
while using the 2.3 tools.
>
> The original project of the imported JAR is using ecore- common- and
> ecore-xmi in version 2.2.0, while my GMF-Editor is using version
> 2.3.2. When instantiating the XXXPackage in a "plain old"
> JavaApplication using the 2.2.0 JARs everything works fine, but when
> running an Eclipse runtime I have to use 2.3.2 for my other models and
> tools, which are based on GMF 2.0
So you're trying to use that older model based on 2.2.x with EMF 2.3.x...
>
>>> So my question is: Is there a general problem with using an EMF-2.2
>>> Package-Class together with EMF-2.3, and is there a way to fix
>>> it/work around it?
>> It should be fine to use 2.2 stuff in a 2.3 runtime, but the opposite
>> is tricker. Can you be more specific about the problems you're seeing?
>
> Everytime I try to get an instance of the Package class, i.e.
> XXXPackage.eINSTANCE, I get a ClassDefNotFound exception "Could not
> initialize class x.x.x.XXXPackage$Literals".
It's still not clear what's causing this problem though. Could you show
a full stack trace including any causing exceptions. Clearly that class
must exists, so likely it's a problem during the initialization which
would have a more informative stack trace.
> Of course the same applies when invoking various introspective methods
> using the package, e.g. eObject.eContents(), where eObject is an
> Object of the imported metamodel. As I said, the imported JAR was
> created using 2.2.0 while the application it has to be used in
> requires 2.3.2.
I know lots of folks, such as DTP for example, were compiling against
EMF 2.2 and then running with EMF 2.3, so I know of no specific problems
that would make that not work.
>
> It would be great if you could help.
I suppose the problem might be as simple as strict version ranges in the
MANIFEST.MF of the model you are using. I need a stack trace or
otherwise be able to reproduce the problem...
>
> Regards,
> Tobias
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Interoperation of different EMF versions? [message #418876 is a reply to message #418784] |
Wed, 30 April 2008 15:30 |
Tobias
Messages: 18
Registered: July 2009 |
Junior Member |
|
|
Hi Ed,
I spent some time investigating the problem and I hope that this will
narrow the cause a bit.
As I wrote I implemented a quite complex Editor and Transformation Tool
as an Eclipse plugin. I used GMF 2 for this and I already realised some
transformations to both EMF and JAXB models as target.
Now I want to write another transformation to some metamodel developed
here in house, which was created with EMF 2.2 due to some restrictions
with the OAW version it has to be used with, I am encountering these
problem. So much to the context.
I have removed all the OAW stuff for testing, so the generated EMF 2.2
model is the only JAR file used in said transformation plugin. However,
these problems occur even when I copy the JAR's source files directly
into my plugin project, so it can not be caused by a the JAR's Manifest.
- the transformation itself works fine, including creating elements
using the Factory and invoking the generated setters
- instantiating the Package in the plugin fails (stack trace below)
- instantiating the Package in a plain old Java main method works fine
- same applies for operations using the Package, such as the
EObject.eXXX methods, the Parser generated by OAW, or writing to an XML
resource
- the Package Class exists and is on first inspection equally structured
as a Package Class generated with EMF 2.3.
I would be really, really glad if you'd have an idea how to fix this
problem. :-)
Regards,
Tobias
Stack trace on invoking eContents on some of the model's elements from
inside a plugin:
java.lang.ExceptionInInitializerError
at
de.dailab.jiactng.jadl.JadlPackage$Literals.<clinit>(JadlPackage.java:4501)
at
de.dailab.jiactng.jadl.impl.ServiceImpl.eStaticClass(Service Impl.java:73)
at org.eclipse.emf.ecore.impl.EObjectImpl.eClass(EObjectImpl.ja va:224)
at
org.eclipse.emf.ecore.util.EContentsEList.createEContentsELi st(EContentsEList.java:57)
at
org.eclipse.emf.ecore.impl.BasicEObjectImpl.eContents(BasicE ObjectImpl.java:812)
at
de.dailab.sercho.vsdt.export.jiactng.trafo.Bpmn2JiacTNGjadlV isitor.save(Bpmn2JiacTNGjadlVisitor.java:86)
...
Caused by: org.eclipse.emf.common.util.WrappedException:
java.lang.ClassNotFoundException: jadl.JadlPackage
at
org.eclipse.emf.ecore.plugin.RegistryReader$EPackageDescript or.getEPackage(RegistryReader.java:215)
at
org.eclipse.emf.ecore.impl.EPackageRegistryImpl.getEPackage( EPackageRegistryImpl.java:114)
at
de.dailab.jiactng.jadl.impl.JadlPackageImpl.init(JadlPackage Impl.java:747)
at de.dailab.jiactng.jadl.JadlPackage.<clinit>(JadlPackage.java:61)
... 47 more
Caused by: java.lang.ClassNotFoundException: jadl.JadlPackage
at java.lang.ClassLoader.findClass(ClassLoader.java:358)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at
org.eclipse.osgi.framework.internal.core.BundleLoader.findCl assInternal(BundleLoader.java:429)
at
org.eclipse.osgi.framework.internal.core.BundleLoader.findCl ass(BundleLoader.java:369)
at
org.eclipse.osgi.framework.internal.core.BundleLoader.findCl ass(BundleLoader.java:357)
at
org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loa dClass(DefaultClassLoader.java:83)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at
org.eclipse.osgi.framework.internal.core.BundleLoader.loadCl ass(BundleLoader.java:289)
at
org.eclipse.osgi.framework.internal.core.BundleHost.loadClas s(BundleHost.java:227)
at
org.eclipse.osgi.framework.internal.core.AbstractBundle.load Class(AbstractBundle.java:1269)
at
org.eclipse.emf.ecore.plugin.RegistryReader$EPackageDescript or.getEPackage(RegistryReader.java:208)
... 50 more
Stack trace on invoking XXXPackage.eINSTANCE on the model's Package
class from inside a plugin:
java.lang.ExceptionInInitializerError
at
de.dailab.sercho.vsdt.export.jiactng.trafo.Bpmn2JiacTNGjadlV isitor.save(Bpmn2JiacTNGjadlVisitor.java:87)
...
Caused by [see above stack trace]
Ed Merks schrieb:
> Tobias,
>
> Comments below.
>
>
> Tobias wrote:
>> Ed Merks schrieb:
>>> Tobias wrote:
>>>> While there are no interoperability problems with the transformation
>>>> itself, there are problems when accessing the XXXPackage class of
>>>> the metamodel implemented in EMF 2.2, which ultimatively prevents me
>>>> from writing the results of the transformation to XML (and causes
>>>> problems in some other places, too).
>>> If you want your model to work with EMF 2.2, you'd need to ensure
>>> that you generate with Java 1.4 compatibility and you need to avoid
>>> the use of generics in your model.. That should produce code that
>>> will work with the 2.2 runtime.
>>
>> Hello Ed,
>>
>> Unfortunately, I do not think that it would be feasible to downgrade
>> my tool to EMF 2.2 to ensure compatibility with the JARs.
> I was only suggesting you target the 2.2 runtime (by targeting Java 1.4)
> while using the 2.3 tools.
>>
>> The original project of the imported JAR is using ecore- common- and
>> ecore-xmi in version 2.2.0, while my GMF-Editor is using version
>> 2.3.2. When instantiating the XXXPackage in a "plain old"
>> JavaApplication using the 2.2.0 JARs everything works fine, but when
>> running an Eclipse runtime I have to use 2.3.2 for my other models and
>> tools, which are based on GMF 2.0
> So you're trying to use that older model based on 2.2.x with EMF 2.3.x...
>>
>>>> So my question is: Is there a general problem with using an EMF-2.2
>>>> Package-Class together with EMF-2.3, and is there a way to fix
>>>> it/work around it?
>>> It should be fine to use 2.2 stuff in a 2.3 runtime, but the opposite
>>> is tricker. Can you be more specific about the problems you're seeing?
>>
>> Everytime I try to get an instance of the Package class, i.e.
>> XXXPackage.eINSTANCE, I get a ClassDefNotFound exception "Could not
>> initialize class x.x.x.XXXPackage$Literals".
> It's still not clear what's causing this problem though. Could you show
> a full stack trace including any causing exceptions. Clearly that class
> must exists, so likely it's a problem during the initialization which
> would have a more informative stack trace.
>> Of course the same applies when invoking various introspective methods
>> using the package, e.g. eObject.eContents(), where eObject is an
>> Object of the imported metamodel. As I said, the imported JAR was
>> created using 2.2.0 while the application it has to be used in
>> requires 2.3.2.
> I know lots of folks, such as DTP for example, were compiling against
> EMF 2.2 and then running with EMF 2.3, so I know of no specific problems
> that would make that not work.
>>
>> It would be great if you could help.
> I suppose the problem might be as simple as strict version ranges in the
> MANIFEST.MF of the model you are using. I need a stack trace or
> otherwise be able to reproduce the problem...
>>
>> Regards,
>> Tobias
|
|
|
| Re: Interoperation of different EMF versions? [message #418877 is a reply to message #418876] |
Wed, 30 April 2008 16:19 |
Ed Merks
Messages: 33218
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------080102090105060805090601
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Tobias,
There's an interesting discrepancy that I notice. I can see that you're
accessing the Literals interface of de.dailab.jiactng.jadl.JadlPackage.
But notice though that the class not found exception says
"ClassNotFoundException: jadl.JadlPackage". I.e.., notice the missing
of "de.dailab.jiactng" qualification? Because it's in the process of
reading the information in the registry, this suggested to me that the
plugin.xml's generated_package extension point's "class" field is
specifying an incorrect name:
<extension point="org.eclipse.emf.ecore.generated_package">
<package
uri="http://www.example.com/Library"
*class="com.example.library.LibraryPackage"*
genModel="model/Library.genmodel"/>
</extension>
Tobias wrote:
> Hi Ed,
>
> I spent some time investigating the problem and I hope that this will
> narrow the cause a bit.
>
> As I wrote I implemented a quite complex Editor and Transformation
> Tool as an Eclipse plugin. I used GMF 2 for this and I already
> realised some transformations to both EMF and JAXB models as target.
> Now I want to write another transformation to some metamodel developed
> here in house, which was created with EMF 2.2 due to some restrictions
> with the OAW version it has to be used with, I am encountering these
> problem. So much to the context.
>
> I have removed all the OAW stuff for testing, so the generated EMF 2.2
> model is the only JAR file used in said transformation plugin.
> However, these problems occur even when I copy the JAR's source files
> directly into my plugin project, so it can not be caused by a the
> JAR's Manifest.
>
> - the transformation itself works fine, including creating elements
> using the Factory and invoking the generated setters
> - instantiating the Package in the plugin fails (stack trace below)
> - instantiating the Package in a plain old Java main method works fine
> - same applies for operations using the Package, such as the
> EObject.eXXX methods, the Parser generated by OAW, or writing to an
> XML resource
> - the Package Class exists and is on first inspection equally
> structured as a Package Class generated with EMF 2.3.
>
> I would be really, really glad if you'd have an idea how to fix this
> problem. :-)
>
> Regards,
> Tobias
>
>
> Stack trace on invoking eContents on some of the model's elements from
> inside a plugin:
> java.lang.ExceptionInInitializerError
> at
> de.dailab.jiactng.jadl.JadlPackage$Literals.<clinit>(JadlPackage.java:4501)
>
> at
> de.dailab.jiactng.jadl.impl.ServiceImpl.eStaticClass(Service Impl.java:73)
> at
> org.eclipse.emf.ecore.impl.EObjectImpl.eClass(EObjectImpl.ja va:224)
> at
> org.eclipse.emf.ecore.util.EContentsEList.createEContentsELi st(EContentsEList.java:57)
>
> at
> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eContents(BasicE ObjectImpl.java:812)
>
> at
> de.dailab.sercho.vsdt.export.jiactng.trafo.Bpmn2JiacTNGjadlV isitor.save(Bpmn2JiacTNGjadlVisitor.java:86)
>
> ...
> Caused by: org.eclipse.emf.common.util.WrappedException:
> java.lang.ClassNotFoundException: jadl.JadlPackage
> at
> org.eclipse.emf.ecore.plugin.RegistryReader$EPackageDescript or.getEPackage(RegistryReader.java:215)
>
> at
> org.eclipse.emf.ecore.impl.EPackageRegistryImpl.getEPackage( EPackageRegistryImpl.java:114)
>
> at
> de.dailab.jiactng.jadl.impl.JadlPackageImpl.init(JadlPackage Impl.java:747)
>
> at de.dailab.jiactng.jadl.JadlPackage.<clinit>(JadlPackage.java:61)
> ... 47 more
> Caused by: java.lang.ClassNotFoundException: jadl.JadlPackage
> at java.lang.ClassLoader.findClass(ClassLoader.java:358)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
> at
> org.eclipse.osgi.framework.internal.core.BundleLoader.findCl assInternal(BundleLoader.java:429)
>
> at
> org.eclipse.osgi.framework.internal.core.BundleLoader.findCl ass(BundleLoader.java:369)
>
> at
> org.eclipse.osgi.framework.internal.core.BundleLoader.findCl ass(BundleLoader.java:357)
>
> at
> org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loa dClass(DefaultClassLoader.java:83)
>
> at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
> at
> org.eclipse.osgi.framework.internal.core.BundleLoader.loadCl ass(BundleLoader.java:289)
>
> at
> org.eclipse.osgi.framework.internal.core.BundleHost.loadClas s(BundleHost.java:227)
>
> at
> org.eclipse.osgi.framework.internal.core.AbstractBundle.load Class(AbstractBundle.java:1269)
>
> at
> org.eclipse.emf.ecore.plugin.RegistryReader$EPackageDescript or.getEPackage(RegistryReader.java:208)
>
> ... 50 more
>
> Stack trace on invoking XXXPackage.eINSTANCE on the model's Package
> class from inside a plugin:
> java.lang.ExceptionInInitializerError
> at
> de.dailab.sercho.vsdt.export.jiactng.trafo.Bpmn2JiacTNGjadlV isitor.save(Bpmn2JiacTNGjadlVisitor.java:87)
>
> ...
> Caused by [see above stack trace]
>
>
>
>
> Ed Merks schrieb:
>> Tobias,
>>
>> Comments below.
>>
>>
>> Tobias wrote:
>>> Ed Merks schrieb:
>>>> Tobias wrote:
>>>>> While there are no interoperability problems with the
>>>>> transformation itself, there are problems when accessing the
>>>>> XXXPackage class of the metamodel implemented in EMF 2.2, which
>>>>> ultimatively prevents me from writing the results of the
>>>>> transformation to XML (and causes problems in some other places,
>>>>> too).
>>>> If you want your model to work with EMF 2.2, you'd need to ensure
>>>> that you generate with Java 1.4 compatibility and you need to avoid
>>>> the use of generics in your model.. That should produce code that
>>>> will work with the 2.2 runtime.
>>>
>>> Hello Ed,
>>>
>>> Unfortunately, I do not think that it would be feasible to downgrade
>>> my tool to EMF 2.2 to ensure compatibility with the JARs.
>> I was only suggesting you target the 2.2 runtime (by targeting Java
>> 1.4) while using the 2.3 tools.
>>>
>>> The original project of the imported JAR is using ecore- common- and
>>> ecore-xmi in version 2.2.0, while my GMF-Editor is using version
>>> 2.3.2. When instantiating the XXXPackage in a "plain old"
>>> JavaApplication using the 2.2.0 JARs everything works fine, but when
>>> running an Eclipse runtime I have to use 2.3.2 for my other models
>>> and tools, which are based on GMF 2.0
>> So you're trying to use that older model based on 2.2.x with EMF
>> 2.3.x...
>>>
>>>>> So my question is: Is there a general problem with using an
>>>>> EMF-2.2 Package-Class together with EMF-2.3, and is there a way to
>>>>> fix it/work around it?
>>>> It should be fine to use 2.2 stuff in a 2.3 runtime, but the
>>>> opposite is tricker. Can you be more specific about the problems
>>>> you're seeing?
>>>
>>> Everytime I try to get an instance of the Package class, i.e.
>>> XXXPackage.eINSTANCE, I get a ClassDefNotFound exception "Could not
>>> initialize class x.x.x.XXXPackage$Literals".
>> It's still not clear what's causing this problem though. Could you
>> show a full stack trace including any causing exceptions. Clearly
>> that class must exists, so likely it's a problem during the
>> initialization which would have a more informative stack trace.
>>> Of course the same applies when invoking various introspective
>>> methods using the package, e.g. eObject.eContents(), where eObject
>>> is an Object of the imported metamodel. As I said, the imported JAR
>>> was created using 2.2.0 while the application it has to be used in
>>> requires 2.3.2.
>> I know lots of folks, such as DTP for example, were compiling against
>> EMF 2.2 and then running with EMF 2.3, so I know of no specific
>> problems that would make that not work.
>>>
>>> It would be great if you could help.
>> I suppose the problem might be as simple as strict version ranges in
>> the MANIFEST.MF of the model you are using. I need a stack trace or
>> otherwise be able to reproduce the problem...
>>>
>>> Regards,
>>> Tobias
--------------080102090105060805090601
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Tobias,<br>
<br>
There's an interesting discrepancy that I notice.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Interoperation of different EMF versions? [message #418918 is a reply to message #418877] |
Fri, 02 May 2008 08:23 |
Tobias
Messages: 18
Registered: July 2009 |
Junior Member |
|
|
Hello Ed,
sorry, I did not find time to check for your reply until now. The funny
thing is: I noticed just the same inconsistency as I read through my
posting once again prior to reading your reply. No idea, why I missed
this... ^^;
Anyway, many thanks for your help. I'll investigate the genmodel right
away to find the problem, or fix it directly in the XML.
Thanks again,
Tobias
Ed Merks schrieb:
> Tobias,
>
> There's an interesting discrepancy that I notice. I can see that you're
> accessing the Literals interface of de.dailab.jiactng.jadl.JadlPackage.
> But notice though that the class not found exception says
> "ClassNotFoundException: jadl.JadlPackage". I.e.., notice the missing
> of "de.dailab.jiactng" qualification? Because it's in the process of
> reading the information in the registry, this suggested to me that the
> plugin.xml's generated_package extension point's "class" field is
> specifying an incorrect name:
>
> <extension point="org.eclipse.emf.ecore.generated_package">
> <package
> uri="http://www.example.com/Library"
> *class="com.example.library.LibraryPackage"*
> genModel="model/Library.genmodel"/>
> </extension>
>
>
>
> Tobias wrote:
>> Hi Ed,
>>
>> I spent some time investigating the problem and I hope that this will
>> narrow the cause a bit.
>>
>> As I wrote I implemented a quite complex Editor and Transformation
>> Tool as an Eclipse plugin. I used GMF 2 for this and I already
>> realised some transformations to both EMF and JAXB models as target.
>> Now I want to write another transformation to some metamodel developed
>> here in house, which was created with EMF 2.2 due to some restrictions
>> with the OAW version it has to be used with, I am encountering these
>> problem. So much to the context.
>>
>> I have removed all the OAW stuff for testing, so the generated EMF 2.2
>> model is the only JAR file used in said transformation plugin.
>> However, these problems occur even when I copy the JAR's source files
>> directly into my plugin project, so it can not be caused by a the
>> JAR's Manifest.
>>
>> - the transformation itself works fine, including creating elements
>> using the Factory and invoking the generated setters
>> - instantiating the Package in the plugin fails (stack trace below)
>> - instantiating the Package in a plain old Java main method works fine
>> - same applies for operations using the Package, such as the
>> EObject.eXXX methods, the Parser generated by OAW, or writing to an
>> XML resource
>> - the Package Class exists and is on first inspection equally
>> structured as a Package Class generated with EMF 2.3.
>>
>> I would be really, really glad if you'd have an idea how to fix this
>> problem. :-)
>>
>> Regards,
>> Tobias
>>
>>
>> Stack trace on invoking eContents on some of the model's elements from
>> inside a plugin:
>> java.lang.ExceptionInInitializerError
>> at
>> de.dailab.jiactng.jadl.JadlPackage$Literals.<clinit>(JadlPackage.java:4501)
>>
>> at
>> de.dailab.jiactng.jadl.impl.ServiceImpl.eStaticClass(Service Impl.java:73)
>> at
>> org.eclipse.emf.ecore.impl.EObjectImpl.eClass(EObjectImpl.ja va:224)
>> at
>> org.eclipse.emf.ecore.util.EContentsEList.createEContentsELi st(EContentsEList.java:57)
>>
>> at
>> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eContents(BasicE ObjectImpl.java:812)
>>
>> at
>> de.dailab.sercho.vsdt.export.jiactng.trafo.Bpmn2JiacTNGjadlV isitor.save(Bpmn2JiacTNGjadlVisitor.java:86)
>>
>> ...
>> Caused by: org.eclipse.emf.common.util.WrappedException:
>> java.lang.ClassNotFoundException: jadl.JadlPackage
>> at
>> org.eclipse.emf.ecore.plugin.RegistryReader$EPackageDescript or.getEPackage(RegistryReader.java:215)
>>
>> at
>> org.eclipse.emf.ecore.impl.EPackageRegistryImpl.getEPackage( EPackageRegistryImpl.java:114)
>>
>> at
>> de.dailab.jiactng.jadl.impl.JadlPackageImpl.init(JadlPackage Impl.java:747)
>>
>> at de.dailab.jiactng.jadl.JadlPackage.<clinit>(JadlPackage.java:61)
>> ... 47 more
>> Caused by: java.lang.ClassNotFoundException: jadl.JadlPackage
>> at java.lang.ClassLoader.findClass(ClassLoader.java:358)
>> at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
>> at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
>> at
>> org.eclipse.osgi.framework.internal.core.BundleLoader.findCl assInternal(BundleLoader.java:429)
>>
>> at
>> org.eclipse.osgi.framework.internal.core.BundleLoader.findCl ass(BundleLoader.java:369)
>>
>> at
>> org.eclipse.osgi.framework.internal.core.BundleLoader.findCl ass(BundleLoader.java:357)
>>
>> at
>> org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loa dClass(DefaultClassLoader.java:83)
>>
>> at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
>> at
>> org.eclipse.osgi.framework.internal.core.BundleLoader.loadCl ass(BundleLoader.java:289)
>>
>> at
>> org.eclipse.osgi.framework.internal.core.BundleHost.loadClas s(BundleHost.java:227)
>>
>> at
>> org.eclipse.osgi.framework.internal.core.AbstractBundle.load Class(AbstractBundle.java:1269)
>>
>> at
>> org.eclipse.emf.ecore.plugin.RegistryReader$EPackageDescript or.getEPackage(RegistryReader.java:208)
>>
>> ... 50 more
>>
>> Stack trace on invoking XXXPackage.eINSTANCE on the model's Package
>> class from inside a plugin:
>> java.lang.ExceptionInInitializerError
>> at
>> de.dailab.sercho.vsdt.export.jiactng.trafo.Bpmn2JiacTNGjadlV isitor.save(Bpmn2JiacTNGjadlVisitor.java:87)
>>
>> ...
>> Caused by [see above stack trace]
>>
>>
>>
>>
>> Ed Merks schrieb:
>>> Tobias,
>>>
>>> Comments below.
>>>
>>>
>>> Tobias wrote:
>>>> Ed Merks schrieb:
>>>>> Tobias wrote:
>>>>>> While there are no interoperability problems with the
>>>>>> transformation itself, there are problems when accessing the
>>>>>> XXXPackage class of the metamodel implemented in EMF 2.2, which
>>>>>> ultimatively prevents me from writing the results of the
>>>>>> transformation to XML (and causes problems in some other places,
>>>>>> too).
>>>>> If you want your model to work with EMF 2.2, you'd need to ensure
>>>>> that you generate with Java 1.4 compatibility and you need to avoid
>>>>> the use of generics in your model.. That should produce code that
>>>>> will work with the 2.2 runtime.
>>>>
>>>> Hello Ed,
>>>>
>>>> Unfortunately, I do not think that it would be feasible to downgrade
>>>> my tool to EMF 2.2 to ensure compatibility with the JARs.
>>> I was only suggesting you target the 2.2 runtime (by targeting Java
>>> 1.4) while using the 2.3 tools.
>>>>
>>>> The original project of the imported JAR is using ecore- common- and
>>>> ecore-xmi in version 2.2.0, while my GMF-Editor is using version
>>>> 2.3.2. When instantiating the XXXPackage in a "plain old"
>>>> JavaApplication using the 2.2.0 JARs everything works fine, but when
>>>> running an Eclipse runtime I have to use 2.3.2 for my other models
>>>> and tools, which are based on GMF 2.0
>>> So you're trying to use that older model based on 2.2.x with EMF
>>> 2.3.x...
>>>>
>>>>>> So my question is: Is there a general problem with using an
>>>>>> EMF-2.2 Package-Class together with EMF-2.3, and is there a way to
>>>>>> fix it/work around it?
>>>>> It should be fine to use 2.2 stuff in a 2.3 runtime, but the
>>>>> opposite is tricker. Can you be more specific about the problems
>>>>> you're seeing?
>>>>
>>>> Everytime I try to get an instance of the Package class, i.e.
>>>> XXXPackage.eINSTANCE, I get a ClassDefNotFound exception "Could not
>>>> initialize class x.x.x.XXXPackage$Literals".
>>> It's still not clear what's causing this problem though. Could you
>>> show a full stack trace including any causing exceptions. Clearly
>>> that class must exists, so likely it's a problem during the
>>> initialization which would have a more informative stack trace.
>>>> Of course the same applies when invoking various introspective
>>>> methods using the package, e.g. eObject.eContents(), where eObject
>>>> is an Object of the imported metamodel. As I said, the imported JAR
>>>> was created using 2.2.0 while the application it has to be used in
>>>> requires 2.3.2.
>>> I know lots of folks, such as DTP for example, were compiling against
>>> EMF 2.2 and then running with EMF 2.3, so I know of no specific
>>> problems that would make that not work.
>>>>
>>>> It would be great if you could help.
>>> I suppose the problem might be as simple as strict version ranges in
>>> the MANIFEST.MF of the model you are using. I need a stack trace or
>>> otherwise be able to reproduce the problem...
>>>>
>>>> Regards,
>>>> Tobias
>
|
|
|
| Re: Interoperation of different EMF versions? [message #418920 is a reply to message #418918] |
Fri, 02 May 2008 10:57 |
Ed Merks
Messages: 33218
Registered: July 2009 |
Senior Member |
|
|
Tobias,
My theory for how it got this way is that the model was generated once
before the Package Prefix was set. This generates the plugin.xml and
the MANIFEST.MF, which never change once they exist. The the GenModel
was changed, and the code was regenerated. The obvious duplication in
the Java code was likely cleaned up by clearing out the source folder,
and then the plugin.xml registration became stale. I wish we'd had time
to get merging working in this release. I know GMF uses a simple
approach of section markers and replacing things within such sections...
Tobias wrote:
> Hello Ed,
>
> sorry, I did not find time to check for your reply until now. The
> funny thing is: I noticed just the same inconsistency as I read
> through my posting once again prior to reading your reply. No idea,
> why I missed this... ^^;
>
> Anyway, many thanks for your help. I'll investigate the genmodel right
> away to find the problem, or fix it directly in the XML.
>
> Thanks again,
> Tobias
>
>
>
> Ed Merks schrieb:
>> Tobias,
>>
>> There's an interesting discrepancy that I notice. I can see that
>> you're accessing the Literals interface of
>> de.dailab.jiactng.jadl.JadlPackage. But notice though that the class
>> not found exception says "ClassNotFoundException: jadl.JadlPackage".
>> I.e.., notice the missing of "de.dailab.jiactng" qualification?
>> Because it's in the process of reading the information in the
>> registry, this suggested to me that the plugin.xml's
>> generated_package extension point's "class" field is specifying an
>> incorrect name:
>>
>> <extension point="org.eclipse.emf.ecore.generated_package">
>> <package
>> uri="http://www.example.com/Library"
>> *class="com.example.library.LibraryPackage"*
>> genModel="model/Library.genmodel"/>
>> </extension>
>>
>>
>>
>> Tobias wrote:
>>> Hi Ed,
>>>
>>> I spent some time investigating the problem and I hope that this
>>> will narrow the cause a bit.
>>>
>>> As I wrote I implemented a quite complex Editor and Transformation
>>> Tool as an Eclipse plugin. I used GMF 2 for this and I already
>>> realised some transformations to both EMF and JAXB models as target.
>>> Now I want to write another transformation to some metamodel
>>> developed here in house, which was created with EMF 2.2 due to some
>>> restrictions with the OAW version it has to be used with, I am
>>> encountering these problem. So much to the context.
>>>
>>> I have removed all the OAW stuff for testing, so the generated EMF
>>> 2.2 model is the only JAR file used in said transformation plugin.
>>> However, these problems occur even when I copy the JAR's source
>>> files directly into my plugin project, so it can not be caused by a
>>> the JAR's Manifest.
>>>
>>> - the transformation itself works fine, including creating elements
>>> using the Factory and invoking the generated setters
>>> - instantiating the Package in the plugin fails (stack trace below)
>>> - instantiating the Package in a plain old Java main method works fine
>>> - same applies for operations using the Package, such as the
>>> EObject.eXXX methods, the Parser generated by OAW, or writing to an
>>> XML resource
>>> - the Package Class exists and is on first inspection equally
>>> structured as a Package Class generated with EMF 2.3.
>>>
>>> I would be really, really glad if you'd have an idea how to fix this
>>> problem. :-)
>>>
>>> Regards,
>>> Tobias
>>>
>>>
>>> Stack trace on invoking eContents on some of the model's elements
>>> from inside a plugin:
>>> java.lang.ExceptionInInitializerError
>>> at
>>> de.dailab.jiactng.jadl.JadlPackage$Literals.<clinit>(JadlPackage.java:4501)
>>>
>>> at
>>> de.dailab.jiactng.jadl.impl.ServiceImpl.eStaticClass(Service Impl.java:73)
>>>
>>> at
>>> org.eclipse.emf.ecore.impl.EObjectImpl.eClass(EObjectImpl.ja va:224)
>>> at
>>> org.eclipse.emf.ecore.util.EContentsEList.createEContentsELi st(EContentsEList.java:57)
>>>
>>> at
>>> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eContents(BasicE ObjectImpl.java:812)
>>>
>>> at
>>> de.dailab.sercho.vsdt.export.jiactng.trafo.Bpmn2JiacTNGjadlV isitor.save(Bpmn2JiacTNGjadlVisitor.java:86)
>>>
>>> ...
>>> Caused by: org.eclipse.emf.common.util.WrappedException:
>>> java.lang.ClassNotFoundException: jadl.JadlPackage
>>> at
>>> org.eclipse.emf.ecore.plugin.RegistryReader$EPackageDescript or.getEPackage(RegistryReader.java:215)
>>>
>>> at
>>> org.eclipse.emf.ecore.impl.EPackageRegistryImpl.getEPackage( EPackageRegistryImpl.java:114)
>>>
>>> at
>>> de.dailab.jiactng.jadl.impl.JadlPackageImpl.init(JadlPackage Impl.java:747)
>>>
>>> at de.dailab.jiactng.jadl.JadlPackage.<clinit>(JadlPackage.java:61)
>>> ... 47 more
>>> Caused by: java.lang.ClassNotFoundException: jadl.JadlPackage
>>> at java.lang.ClassLoader.findClass(ClassLoader.java:358)
>>> at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
>>> at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
>>> at
>>> org.eclipse.osgi.framework.internal.core.BundleLoader.findCl assInternal(BundleLoader.java:429)
>>>
>>> at
>>> org.eclipse.osgi.framework.internal.core.BundleLoader.findCl ass(BundleLoader.java:369)
>>>
>>> at
>>> org.eclipse.osgi.framework.internal.core.BundleLoader.findCl ass(BundleLoader.java:357)
>>>
>>> at
>>> org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loa dClass(DefaultClassLoader.java:83)
>>>
>>> at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
>>> at
>>> org.eclipse.osgi.framework.internal.core.BundleLoader.loadCl ass(BundleLoader.java:289)
>>>
>>> at
>>> org.eclipse.osgi.framework.internal.core.BundleHost.loadClas s(BundleHost.java:227)
>>>
>>> at
>>> org.eclipse.osgi.framework.internal.core.AbstractBundle.load Class(AbstractBundle.java:1269)
>>>
>>> at
>>> org.eclipse.emf.ecore.plugin.RegistryReader$EPackageDescript or.getEPackage(RegistryReader.java:208)
>>>
>>> ... 50 more
>>>
>>> Stack trace on invoking XXXPackage.eINSTANCE on the model's Package
>>> class from inside a plugin:
>>> java.lang.ExceptionInInitializerError
>>> at
>>> de.dailab.sercho.vsdt.export.jiactng.trafo.Bpmn2JiacTNGjadlV isitor.save(Bpmn2JiacTNGjadlVisitor.java:87)
>>>
>>> ...
>>> Caused by [see above stack trace]
>>>
>>>
>>>
>>>
>>> Ed Merks schrieb:
>>>> Tobias,
>>>>
>>>> Comments below.
>>>>
>>>>
>>>> Tobias wrote:
>>>>> Ed Merks schrieb:
>>>>>> Tobias wrote:
>>>>>>> While there are no interoperability problems with the
>>>>>>> transformation itself, there are problems when accessing the
>>>>>>> XXXPackage class of the metamodel implemented in EMF 2.2, which
>>>>>>> ultimatively prevents me from writing the results of the
>>>>>>> transformation to XML (and causes problems in some other places,
>>>>>>> too).
>>>>>> If you want your model to work with EMF 2.2, you'd need to ensure
>>>>>> that you generate with Java 1.4 compatibility and you need to
>>>>>> avoid the use of generics in your model.. That should produce
>>>>>> code that will work with the 2.2 runtime.
>>>>>
>>>>> Hello Ed,
>>>>>
>>>>> Unfortunately, I do not think that it would be feasible to
>>>>> downgrade my tool to EMF 2.2 to ensure compatibility with the JARs.
>>>> I was only suggesting you target the 2.2 runtime (by targeting Java
>>>> 1.4) while using the 2.3 tools.
>>>>>
>>>>> The original project of the imported JAR is using ecore- common-
>>>>> and ecore-xmi in version 2.2.0, while my GMF-Editor is using
>>>>> version 2.3.2. When instantiating the XXXPackage in a "plain old"
>>>>> JavaApplication using the 2.2.0 JARs everything works fine, but
>>>>> when running an Eclipse runtime I have to use 2.3.2 for my other
>>>>> models and tools, which are based on GMF 2.0
>>>> So you're trying to use that older model based on 2.2.x with EMF
>>>> 2.3.x...
>>>>>
>>>>>>> So my question is: Is there a general problem with using an
>>>>>>> EMF-2.2 Package-Class together with EMF-2.3, and is there a way
>>>>>>> to fix it/work around it?
>>>>>> It should be fine to use 2.2 stuff in a 2.3 runtime, but the
>>>>>> opposite is tricker. Can you be more specific about the problems
>>>>>> you're seeing?
>>>>>
>>>>> Everytime I try to get an instance of the Package class, i.e.
>>>>> XXXPackage.eINSTANCE, I get a ClassDefNotFound exception "Could
>>>>> not initialize class x.x.x.XXXPackage$Literals".
>>>> It's still not clear what's causing this problem though. Could you
>>>> show a full stack trace including any causing exceptions. Clearly
>>>> that class must exists, so likely it's a problem during the
>>>> initialization which would have a more informative stack trace.
>>>>> Of course the same applies when invoking various introspective
>>>>> methods using the package, e.g. eObject.eContents(), where eObject
>>>>> is an Object of the imported metamodel. As I said, the imported
>>>>> JAR was created using 2.2.0 while the application it has to be
>>>>> used in requires 2.3.2.
>>>> I know lots of folks, such as DTP for example, were compiling
>>>> against EMF 2.2 and then running with EMF 2.3, so I know of no
>>>> specific problems that would make that not work.
>>>>>
>>>>> It would be great if you could help.
>>>> I suppose the problem might be as simple as strict version ranges
>>>> in the MANIFEST.MF of the model you are using. I need a stack
>>>> trace or otherwise be able to reproduce the problem...
>>>>>
>>>>> Regards,
>>>>> Tobias
>>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Thu Sep 26 11:13:46 GMT 2024
Powered by FUDForum. Page generated in 0.05141 seconds |
] 
Search
Help
Register
Login
Home
