Home » Modeling » EMF » Runtime vs Development Time Package references
| Runtime vs Development Time Package references [message #428372] |
Wed, 18 March 2009 15:15  |
 J F
Messages: 256
Registered: July 2009 |
Senior Member |
|
|
1/ There are two ways of referencing types from another EMF plugin which
defines Epackages. One is to reference them the development time way
which leads to references of the form ;
<eClassifiers xsi:type="ecore:EClass" name="B"
eSuperTypes="platform:/plugin/PluginName/modelDirectory/Model.ecore#//A "/>
Another is to reference them the runtime way;
<eClassifiers xsi:type="ecore:EClass" name="B" eSuperTypes="Package
NSURI#//A"/>
2/ Say we have an existing plugin ModelA which defines an EPackage PkgA
with an EClass A and it has been generated to export it in the normal EMF
manner and is in my plugins directory. PkgA's NSURI is
http://nowehere/Model/A. We want to extend that Model in a plugin ModelB
so that we have an EClass B which extends EClass A. We create the ecore
model for plugin Model B b.ecore. We have to reference A as the super
type of B, so we have to do a Load Resource, which we do and choose to
reference the *** runtime version *** of PkgA. This all works fine, and we
save and reload and redit etc. Now we wish to generate Model B. We create
a genmodel for b.ecore, it loads fine, but when we come to finish we get
Socket error, because
org.eclipse.emf.importer.ModelImporter.saveGenModelAndEPacka ges is trying
to save a copy of the GenPackage that it created to wrap PkgA. If we had
used the *** development time version *** way of referencing PkgA we would
have been fine, as it would have loaded the GenPackage found in the Model
A plugin.
3/ Suppose Model A defines an EClass PA which extends EPackage. We have
the accompanying edit and editor plugins in our plugins directory. We
create a Model C plugin and use the ModelA Editor to create a new model
with a PA package at its root, and add an A (I.e. a specialized EClass )
to its classifiers. We (re)name this model C.ecore, and create a gen model
for it, which works fine, eventhough there are no explicit design time
references to PkgA.
My Questions;
a) Is it intentional that I cannot use runtime package references in my
ecore model if I wish to create a genmodel from it? Or have I got some
other problem?
b) If it is intentional... Please could you help me understand why the
GenModel is forbidden from using / cannot use runtime references surely
it resolves these to an EPackage in the EPackage registry from which it
ought to be able to locate the genmodel?
With the design time references I have to know the plugin name, and model
location in the plugin. I have a tool which exports Ecore models from an
non eclipse place and which would be simpler to maintain without having to
find these (at the momment I have to run up OSGI, load a registry and work
from there but I already have the Epackage nsuris in my source data).
======= ModelA =====
<?xml version="1.0" encoding="UTF-8"?>
<ecore:EPackage xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="PkgA"
nsURI="http://his.co.uk/Model/A" nsPrefix="ma">
<eClassifiers xsi:type="ecore:EClass" name="A"
eSuperTypes=" platform:/plugin/org.eclipse.emf.ecore/model/Ecore.ecore#//E Class "/>
<eClassifiers xsi:type="ecore:EClass" name="PA"
eSuperTypes=" platform:/plugin/org.eclipse.emf.ecore/model/Ecore.ecore#//E Package "/>
</ecore:EPackage>
== Good Model B with designtime references ==
<?xml version="1.0" encoding="UTF-8"?>
<ecore:EPackage xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="PkgB"
nsURI="http://his.co.uk/Model/B" nsPrefix="mb">
<eClassifiers xsi:type="ecore:EClass" name="B"
eSuperTypes="platform:/plugin/ModelA/model/A.ecore#//A"/>
</ecore:EPackage>
== Bad Model B with runtime references ==
<?xml version="1.0" encoding="UTF-8"?>
<ecore:EPackage xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="PkgB"
nsURI="http://his.co.uk/Model/B" nsPrefix="mb">
<eClassifiers xsi:type="ecore:EClass" name="B"
eSuperTypes="http://his.co.uk/Model/A#//A"/>
</ecore:EPackage>
== Model C entirely runtime ==
<?xml version="1.0" encoding="UTF-8"?>
<ma:PA xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ma="http://his.co.uk/Model/A" name="APA"
nsURI="http://hisl.co.uk/Model/APA" nsPrefix="apa">
<eClassifiers xsi:type="ma:A" name="AnA"/>
</ma:PA>
|
|
|
| Re: Runtime vs Development Time Package references [message #428380 is a reply to message #428372] |
Wed, 18 March 2009 18:28  |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------070708010205040401040209
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
JF,
Comments below.
JF wrote:
> 1/ There are two ways of referencing types from another EMF plugin
> which defines Epackages. One is to reference them the ?development
> time? way which leads to references of the form ;
>
> <eClassifiers xsi:type="ecore:EClass" name="B"
> eSuperTypes="platform:/plugin/PluginName/modelDirectory/Model.ecore#//A "/>
>
It's also often the case that you can refer to the version of this
that's in your workspace so you'd have a relative address within the
workspace.
>
> Another is to reference them the runtime way;
>
> <eClassifiers xsi:type="ecore:EClass" name="B" eSuperTypes="Package
> NSURI#//A"/>
That's generally not a good thing for a model which you will generate...
>
> 2/ Say we have an existing plugin ModelA which defines an EPackage
> ?PkgA? with an EClass A and it has been generated to export it in the
> normal EMF manner and is in my plugins directory. PkgA's NSURI is
> ?http://nowehere/Model/A?. We want to extend that Model in a plugin
> ModelB so that we have an EClass B which extends EClass A.
We do this a lot ourselves.
> We create the ecore model for plugin Model B ?b.ecore?. We have to
> reference A as the super type of B, so we have to do a ?Load
> Resource?, which we do and choose to reference the *** runtime version
> *** of PkgA.
No, that's a bad idea.
> This all works fine,
So it might seem. I only added that feature so that folks who wanted to
build a live model they didn't intend to generate could make that work...
> and we save and reload and redit etc. Now we wish to generate Model B.
The problem approaches...
> We create a genmodel for b.ecore, it loads fine, but when we come to
> finish we get Socket error, because
> org.eclipse.emf.importer.ModelImporter.saveGenModelAndEPacka ges is
> trying to save a copy of the GenPackage that it created to wrap PkgA.
> If we had used the *** development time version *** way of referencing
> PkgA we would have been fine, as it would have loaded the GenPackage
> found in the Model A plugin.
So bad idea...
>
> 3/ Suppose Model A defines an EClass ?PA? which extends EPackage.
Oh no. Extensions of Ecore. We're going from bad to worse! And of
course Ecore is more special than any other package...
> We have the accompanying edit and editor plugins in our plugins
> directory. We create a Model C plugin and use the ModelA Editor to
> create a new model with a PA package at its root, and add an A (I.e. a
> specialized EClass ) to its classifiers. We (re)name this model
> C.ecore, and create a gen model for it, which works fine, eventhough
> there are no explicit ?design time? references to PkgA.
> My Questions;
> a) Is it intentional that I cannot use runtime package references in
> my ecore model if I wish to create a genmodel from it? Or have I got
> some other problem?
Yes, it's intentional. If you're going to generate the model, use the
development time versions of all the EPackages because those are the
versions for which there are associated GenModels and you'll need their
information to generate properly (to know how the base model was generated).
> b) If it is intentional... Please could you help me understand why the
> GenModel is forbidden from using / cannot use runtime references ?
> surely it resolves these to an EPackage in the EPackage registry from
> which it ought to be able to locate the genmodel?
It does. But that's a *different EPackage* than the one you get loading
the serialized .ecore file.
> With the design time references I have to know the plugin name, and
> model location in the plugin.
Yes.
> I have a tool which exports Ecore models from an non eclipse place and
> which would be simpler to maintain without having to find these (at
> the momment I have to run up OSGI, load a registry and work from there
> ? but I already have the Epackage nsuris in my source data).
I can't think of anything to suggest...
>
> ======= ModelA =====
>
> <?xml version="1.0" encoding="UTF-8"?>
> <ecore:EPackage xmi:version="2.0"
> xmlns:xmi="http://www.omg.org/XMI"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="PkgA"
> nsURI="http://his.co.uk/Model/A" nsPrefix="ma">
> <eClassifiers xsi:type="ecore:EClass" name="A"
> eSuperTypes=" platform:/plugin/org.eclipse.emf.ecore/model/Ecore.ecore#//E Class "/>
>
> <eClassifiers xsi:type="ecore:EClass" name="PA"
> eSuperTypes=" platform:/plugin/org.eclipse.emf.ecore/model/Ecore.ecore#//E Package "/>
>
> </ecore:EPackage>
>
>
>
> == ?Good? Model B with designtime references ==
> <?xml version="1.0" encoding="UTF-8"?>
> <ecore:EPackage xmi:version="2.0"
> xmlns:xmi="http://www.omg.org/XMI"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="PkgB"
> nsURI="http://his.co.uk/Model/B" nsPrefix="mb">
> <eClassifiers xsi:type="ecore:EClass" name="B"
> eSuperTypes="platform:/plugin/ModelA/model/A.ecore#//A"/>
> </ecore:EPackage>
>
>
> == ?Bad? Model B with runtime references ==
> <?xml version="1.0" encoding="UTF-8"?>
> <ecore:EPackage xmi:version="2.0"
> xmlns:xmi="http://www.omg.org/XMI"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="PkgB"
> nsURI="http://his.co.uk/Model/B" nsPrefix="mb">
> <eClassifiers xsi:type="ecore:EClass" name="B"
> eSuperTypes="http://his.co.uk/Model/A#//A"/>
> </ecore:EPackage>
>
> == Model C entirely runtime ==
> <?xml version="1.0" encoding="UTF-8"?>
> <ma:PA xmi:version="2.0"
> xmlns:xmi="http://www.omg.org/XMI"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:ma="http://his.co.uk/Model/A" name="APA"
> nsURI="http://hisl.co.uk/Model/APA" nsPrefix="apa">
> <eClassifiers xsi:type="ma:A" name="AnA"/>
> </ma:PA>
>
>
>
--------------070708010205040401040209
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">
JF,<br>
<br>
Comments below.<br>
<br>
<br>
JF wrote:
<blockquote
cite="mid:9994181a492954e70ef23a5175b9d0d8$1@www.eclipse.org"
type="cite">1/
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| Re: Runtime vs Development Time Package references [message #428384 is a reply to message #428382] |
Wed, 18 March 2009 20:03 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
JF,
Comments below.
JF wrote:
> Thanks ed, sorry for being so dense, I've got a bad cold!
A head cold I take it. :-P
>
> So whats the difference between the two EPackages ( I think i've
> been here before - sorry)? Is one the "dynamic" one loaded from the
> .ecore file in the plugin located along side the .genmodel which when
> loaded will effectively be an instance of class EPackage, and the
> other, the runtime one, the one you construct when you parse the
> generated package extension "org.eclipse.emf.ecore.generated_package"
> which will be an instance of a subclass of EPackage generated from the
> .genmodel?
Yes. As an example, consider what you get back when you do
EcoreUtil.copy(EcorePackage.eINSTANCE). The result won't be an instance
of EcorePackage...
>
>>> Oh no. Extensions of Ecore. We're going from bad to worse!
>
> You mean that's not something which is recommended generally or just
> in this context?
I always warn people that if they extend Ecore, and by that I mean
EModelElement or lower, that they'd better not expect release to release
binary compatibility for Ecore's Impl classes because I'm not
guaranteeing that. If that's not a problem, then it's not a problem...
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Wed Apr 24 20:55:16 GMT 2024
Powered by FUDForum. Page generated in 0.27703 seconds |
] 
Search
Help
Register
Login
Home
