Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » UML2 » Re: [CDO] Importing a UML model
Re: [CDO] Importing a UML model [message #781185] Fri, 20 January 2012 08:19
Eclipse User
I post this also on the UML2 newsgroup because the root of the problem
is probably more UML2 than EMF/CDO specific. Sorry for cross-posting.

The underlying problem seems to be that UML elements in the UML.ecore
model use (not only instantiate) elements in its metamodel
(Ecore.ecore). This seems odd to me, what are the reasons for leaving
the UML model that way? Kenn said that there were pros and cons to this
modeling style [1], but I couldn't find anything about the benefits.

Any hints on how I could possibly realize the use case described below
are of course also very welcome... :-)

Thanks!

Johannes


[1]: http://www.eclipse.org/forums/index.php/t/151997/



Am 19.01.2012 12:08, schrieb Johannes Beichter:
> Hi everybody,
>
> I'm trying to recursively import UML models and their dependencies
> (referenced models) into CDO using its legacy mode.
>
> E.g., for a simple model with a property of type String I find
> dependencies from
>
> pathmap://UML_LIBRARIES/UMLPrimitiveTypes.library.uml
> pathmap://UML_PROFILES/Standard.profile.uml
> pathmap://UML_METAMODELS/UML.metamodel.uml
> pathmap://UML_METAMODELS/Ecore.metamodel.uml
> pathmap://UML_PROFILES/Ecore.profile.uml
>
> and copy each of these models to a new CDO resource. This is done by a
> class that extends EcoreUtil.Copier with a modified copyReference()
> method. This method checks if the model (resource) of a referenced
> EObject is already imported, and if not it first imports this model and
> then sets the reference.
>
> Eike's patched uml plugin [1] contains replacements for EModelElement
> (ModelElement) and EAnnotation (Annotation). I renamed them back to
> EModelElement and EAnnotation in order to use the uml files as they are,
> but there seem to be more dependencies on Ecore's EModelElement.
> EcoreFactoryImpl throws
>
> java.lang.IllegalArgumentException: The class 'EModelElement' is not a
> valid classifier
>
> on the server during the commit step (see the stack trace below). Trying
> to debug it, I found that (down the stack) EFactoryImpl.create wants to
> create an instance of
>
> org.eclipse.emf.ecore.impl.EClassImpl@10285d8 (name: Profile)
> (instanceClassName: null) (abstract: false, interface: false)
>
> and CDOModelUtil.readPackage finds uri values like
>
> http://www.eclipse.org/uml2/schemas/Ecore/5
>
> so I concluded that there are more dependencies from Ecore's
> EModelElement in the uml files of the resources plugin.
>
> And that's my question, does anybody know if/how these dependencies can
> be changed from the Ecore version to the patched one?
>
> Any help would be appreciated!
>
> Johannes
>
>
> [1]: https://bugs.eclipse.org/bugs/show_bug.cgi?id=267222
>
> Stack trace:
> java.lang.IllegalArgumentException: The class 'EModelElement' is not a
> valid classifier
> at
> org.eclipse.emf.ecore.impl.EcoreFactoryImpl.create(EcoreFactoryImpl.java:105)
>
> at org.eclipse.emf.ecore.impl.EFactoryImpl.create(EFactoryImpl.java:266)
> at
> org.eclipse.emf.ecore.xmi.impl.XMLHelperImpl.createObject(XMLHelperImpl.java:891)
>
> at
> org.eclipse.emf.ecore.xmi.impl.XMLHelperImpl.createObject(XMLHelperImpl.java:928)
>
> at
> org.eclipse.emf.ecore.xmi.impl.XMLHandler.createObjectFromFactory(XMLHandler.java:2186)
>
> at
> org.eclipse.emf.ecore.xmi.impl.XMLHandler.createObjectByType(XMLHandler.java:1330)
>
> at
> org.eclipse.emf.ecore.xmi.impl.XMLHandler.createTopObject(XMLHandler.java:1468)
>
> at
> org.eclipse.emf.ecore.xmi.impl.XMLHandler.processElement(XMLHandler.java:1019)
>
> at
> org.eclipse.emf.ecore.xmi.impl.XMIHandler.processElement(XMIHandler.java:87)
>
> at
> org.eclipse.emf.ecore.xmi.impl.XMLHandler.startElement(XMLHandler.java:1001)
>
> at
> org.eclipse.emf.ecore.xmi.impl.XMLHandler.startElement(XMLHandler.java:712)
> at
> org.eclipse.emf.ecore.xmi.impl.XMIHandler.startElement(XMIHandler.java:169)
> at
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanStartElement(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown
> Source)
> at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown
> Source)
> at javax.xml.parsers.SAXParser.parse(Unknown Source)
> at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl.java:181)
> at
> org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad(XMLResourceImpl.java:242)
>
> at
> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(ResourceImpl.java:1511)
>
> at
> org.eclipse.emf.cdo.common.model.EMFUtil.createEPackage(EMFUtil.java:304)
> at
> org.eclipse.emf.cdo.common.model.CDOModelUtil.readPackage(CDOModelUtil.java:505)
>
> at
> org.eclipse.emf.cdo.internal.common.model.CDOPackageUnitImpl.read(CDOPackageUnitImpl.java:301)
>
> at
> org.eclipse.emf.cdo.internal.common.protocol.CDODataInputImpl.readCDOPackageUnit(CDODataInputImpl.java:107)
>
> at
> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTransactionIndication.indicatingCommit(CommitTransactionIndication.java:137)
>
> at
> org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTransactionIndication.indicating(CommitTransactionIndication.java:91)
>
> at
> org.eclipse.emf.cdo.server.internal.net4j.protocol.CDOServerIndicationWithMonitoring.indicating(CDOServerIndicationWithMonitoring.java:109)
>
> at
> org.eclipse.net4j.signal.IndicationWithMonitoring.indicating(IndicationWithMonitoring.java:84)
>
> at
> org.eclipse.net4j.signal.IndicationWithResponse.doExtendedInput(IndicationWithResponse.java:90)
>
> at org.eclipse.net4j.signal.Signal.doInput(Signal.java:326)
> at
> org.eclipse.net4j.signal.IndicationWithResponse.execute(IndicationWithResponse.java:63)
>
> at
> org.eclipse.net4j.signal.IndicationWithMonitoring.execute(IndicationWithMonitoring.java:63)
>
> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:251)
> at org.eclipse.net4j.signal.Signal.run(Signal.java:147)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
>
>
>
> Am 24.03.2011 11:33, schrieb Peter:
>> Hi Eike,
>> thank you for your answer!
>> I tried it out and it seems to work. I can create UML Resources and
>> import UML Resources. When I try to save the imported Models with its
>> References "pathmap://UML_LIBRARIES/...", "pathmap://UML_PROFILES/..."
>> etc. the Error "java.net.UnknownServiceException: protocol doesn't
>> support output" appears. I also can´t import those models...
>> I don´t know enough to investigate this so hopefully you sponsor has the
>> wish for a native CDO-UML2 implementation and share it with us.
>> Have a great day.
>> Peter
>>
>> Am 23.03.2011 16:47, schrieb Eike Stepper:
>>> Hi Peter,
>>>
>>> CDO does have this legacy mode since a while and it seems to work with
>>> all the models we've tried it out with, but I myself have not tested it
>>> with UML2. If you will try it out please report your experiences here.
>>> This brief article may help you: http://wiki.eclipse.org/CDO/Legacy_Mode
>>>
>>> As far as I know nobody has worked on providing a CDO native version of
>>> UML2 so far. I'm currently negotiating with a new sponsor that also has
>>> an interest in UML on top of CDO and they may put it on their wish list.
>>> My feeling is that model evolution support ranks higher on their scale.
>>> It's all not very settled, yet.
>>>
>>> Cheers
>>> /Eike
>>>
>>> ----
>>> http://www.esc-net.de
>>> http://thegordian.blogspot.com
>>> http://twitter.com/eikestepper
>>
>>
Previous Topic:Text generation
Next Topic:UML code generation
Goto Forum:
  


Current Time: Fri Aug 29 16:18:48 EDT 2014

Powered by FUDForum. Page generated in 0.01584 seconds