Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Contributing extended models in Eclipse and as stand-alone EMF.
Contributing extended models in Eclipse and as stand-alone EMF. [message #869233] Thu, 03 May 2012 05:21 Go to next message
Frank Goldwin is currently offline Frank Goldwin
Messages: 10
Registered: May 2012
Junior Member
Hi,

I have a number of message dictionaries specified in XML. Each has a different XML format.
I have the XSD for each one so I can build an EMF model for each one (DictionaryType1, DictionaryType2, etc).
I will create a plugin for each one so I can contribute different dictionary types to an application.
All models will implement a StandardDictionary interface that I define, so they can be handled in the same way by clients.

Then I want to build a DictionaryLibrary (DL) model to contain any number of these dictionaries.
The users should be able to copy a dictionary XML file into the workspace, then add a StandardDictionary node to the DL with the DL editor, specifying an alias for the dictionary and its XML target file in the workspace.
The DL then will be the application entry point to request dictionaries objects (by alias), both in Eclipse and stand-alone EMF.

Note: I will model the containment as cross-resource containment, so dictionaries remain in their XML file,
and the DL in its own file. This way I also get lazy loading through EMF proxy resolution.

The problem I'm having is 2 folds:

1 - I'm not sure how to model the StandardDictionary element in the DL model.
Should I model it as an interface?
Should I then have the the root node of each DictionaryTypeX model implement the StandardDictionary?
Like every EMF model the DictionaryTypeX plugins contribute to the org.eclipse.emf.ecore.generated_package extension point.
Thus in the DL editor I can work out the list of DictionaryTypeX registered.
Then, on a right click, I can display the list of available dictionary types for the user to choose, and then create the correct element as a child node of the Dictionary library.
Will this setup allow me to add a number of heterogeneous dictionary elements to the DL root in the DL editor?
Can EMF automate discovery of the list of registered dictionary types and display it in the popup menu?

2 - During stand-alone execution the DictionaryTypeX packages don't register themselves.
The DL model will be loaded from its file and for each child node should then use the correct DictionaryTypeX model to load it.
Does EMF provide the capability to have this happen automatically, maybe through adapter factories?
Or should I somehow provide some helper code to make this happen?

Note that XML dictionary files come from non-EMF sources and thus will not contain a namespace.
Ideally I would prefer not to modify them but I can if strictly necessary.

I feel I can use EMF capabilities to make this happen smoothly without adding any or much of my code but I'm not entirely sure how.
Any help would be much appreciated.

Than you.
Frank
Re: Contributing extended models in Eclipse and as stand-alone EMF. [message #869244 is a reply to message #869233] Thu, 03 May 2012 05:41 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 26152
Registered: July 2009
Senior Member
Frank,

Comments below.

On 03/05/2012 7:21 AM, Frank Goldwin wrote:
> Hi,
>
> I have a number of message dictionaries specified in XML. Each has a
> different XML format.
> I have the XSD for each one so I can build an EMF model for each one
> (DictionaryType1, DictionaryType2, etc).
> I will create a plugin for each one so I can contribute different
> dictionary types to an application.
> All models will implement a StandardDictionary interface that I
> define, so they can be handled in the same way by clients.
>
> Then I want to build a DictionaryLibrary (DL) model to contain any
> number of these dictionaries.
As an XSD?
> The users should be able to copy a dictionary XML file into the
> workspace, then add a StandardDictionary node to the DL with the DL
> editor, specifying an alias for the dictionary and its XML target file
> in the workspace.
An alias?
> The DL then will be the application entry point to request
> dictionaries objects (by alias), both in Eclipse and stand-alone EMF.
>
> Note: I will model the containment as cross-resource containment, so
> dictionaries remain in their XML file,
> and the DL in its own file. This way I also get lazy loading through
> EMF proxy resolution.
Does it need to be containment at all?
>
> The problem I'm having is 2 folds:
>
> 1 - I'm not sure how to model the StandardDictionary element in the DL
> model.
> Should I model it as an interface?
You'll need an EClass. An interface just means there's no generated
Impl for that EClass but only for derived classes. If you make it
abstract there will be an Impl but you won't be able to create
instances, only derived instances. It's typically preferred to have an
Impl because otherwise each derived class needs its own "copy" of the
Impl details.
> Should I then have the the root node of each DictionaryTypeX model
> implement the StandardDictionary?
You can if you want.
> Like every EMF model the DictionaryTypeX plugins contribute to the
> org.eclipse.emf.ecore.generated_package extension point.
> Thus in the DL editor I can work out the list of DictionaryTypeX
> registered.
> Then, on a right click, I can display the list of available dictionary
> types for the user to choose, and then create the correct element as a
> child node of the Dictionary library.
> Will this setup allow me to add a number of heterogeneous dictionary
> elements to the DL root in the DL editor?
> Can EMF automate discovery of the list of registered dictionary types
> and display it in the popup menu?
Sounds like this case:
http://ed-merks.blogspot.de/2008/01/creating-children-you-didnt-know.html
>
> 2 - During stand-alone execution the DictionaryTypeX packages don't
> register themselves.
> The DL model will be loaded from its file and for each child node
> should then use the correct DictionaryTypeX model to load it.
> Does EMF provide the capability to have this happen automatically,
> maybe through adapter factories?
> Or should I somehow provide some helper code to make this happen?
You need to ensure that each package is initialized, i.e.,
XyzPackage.eINSTANCE.eClass() is an idiom for ensuring that the package
instance is initialized and registered in the global package registry.
>
> Note that XML dictionary files come from non-EMF sources and thus will
> not contain a namespace.
> Ideally I would prefer not to modify them but I can if strictly
> necessary.
I'm not sure how it will be possible for EMF (or any other tool) to know
which XSD and hence which EPackage specifies the syntax for what it's
supposed to read...
>
> I feel I can use EMF capabilities to make this happen smoothly without
> adding any or much of my code but I'm not entirely sure how.
The last part about no namespace yet multiple schemas sounds like the
worst problem. Somehow you'll have to know based on the file name or
the initial file contents which generated resource factory and hence
which package should be used to process the contents.
> Any help would be much appreciated.
>
> Than you.
> Frank
Re: Contributing extended models in Eclipse and as stand-alone EMF. [message #869817 is a reply to message #869244] Fri, 04 May 2012 12:00 Go to previous messageGo to next message
Frank Goldwin is currently offline Frank Goldwin
Messages: 10
Registered: May 2012
Junior Member
Thank you Ed.

I'm trying your suggestions. Few points:

1 - I've tried your childCreationExtenders tutorial (recreating your models) and it works for me too.
When I generate a model from XSD though and set childCreatingExtenders = true on the generator, the extension is not created in plugin.xml.
I have found out the reason and it might be a bug.
Say I generate the XSD and I end up with a model with an element called Link (like in your example).
The element contains some ExtendedMetaData because it came from XSD.
The extension point won't be created unless I remove the "name -> xxx_._type" map entry from its ExtendedMetaData.
It took me a while to find this out. I've verified it many times. Maybe you can try that too please?
Or should I just file a bug and spare your time?

2 - You mention initializing each package during a stand-alone run using the XyzPackage.eINSTANCE.eClass() idiom.
At run time though I don't know which packages are available.
Is there any way to find out? Even a list of every package in the system would do as I could discover those I'm interested in using wildcards against their name.

Thank you.

Regards,
Frank
Re: Contributing extended models in Eclipse and as stand-alone EMF. [message #869851 is a reply to message #869817] Fri, 04 May 2012 13:51 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 26152
Registered: July 2009
Senior Member
Frank,

Comments below.

On 04/05/2012 2:01 PM, Frank Goldwin wrote:
> Thank you Ed.
>
> I'm trying your suggestions. Few points:
>
> 1 - I've tried your childCreationExtenders tutorial (recreating your
> models) and it works for me too.
> When I generate a model from XSD though and set childCreatingExtenders
> = true on the generator, the extension is not created in plugin.xml.
Note that plugin.xml doesn't regenerate once it exists, so you'll need
to delete it and regenerate it (merging back in any changes you've made
by hand).
> I have found out the reason and it might be a bug.
> Say I generate the XSD and I end up with a model with an element
> called Link (like in your example).
> The element contains some ExtendedMetaData because it came from XSD.
> The extension point won't be created unless I remove the "name ->
> xxx_._type" map entry from its ExtendedMetaData.
You won't be able to use anonymous types for this purpose. It won't be
possible to create a conforming serialization...
> It took me a while to find this out. I've verified it many times.
> Maybe you can try that too please?
> Or should I just file a bug and spare your time?
I don't think it's a bug, if I understand correctly. Anonymous can't be
used where an xsi:type will be necessary because they have no names. So
better you give the type a name in the schema, and then it will work.
>
> 2 - You mention initializing each package during a stand-alone run
> using the XyzPackage.eINSTANCE.eClass() idiom.
> At run time though I don't know which packages are available.
> Is there any way to find out?
No.
> Even a list of every package in the system would do as I could
> discover those I'm interested in using wildcards against their name.
That's a problem without some time of component model as in OSGi. You
need active initialization because nothing is registered in a way that
can be discovered. In Eclipse you shouldn't need to do any of that kind
of explicit initialization; the registrations in the plugin.xmls will
suffice. Of course you have to be sure they are regenerated.
>
> Thank you.
>
> Regards,
> Frank
>
Re: Contributing extended models in Eclipse and as stand-alone EMF. [message #890983 is a reply to message #869233] Sat, 23 June 2012 16:57 Go to previous messageGo to next message
Missing name Missing name is currently offline Missing name Missing name
Messages: 1
Registered: April 2011
Junior Member
For anyone trying to solve the same problem, this is what I've done.
Because I need the functionality of my EMF plugins to also be available in stand-alone mode, I've used the Java ServiceLoader class to do that. (You can find many examples online).
I've added a "loader" class into each plugin. All it does is initializing the EMF package.
Then I've used the Java ServiceLoader to execute each 'loader' class, therefore initializing the contributed packages.

I'm not claiming this is the best approach but in my case it has resulted in a clean working solution.

Regards,
Frank
Re: Contributing extended models in Eclipse and as stand-alone EMF. [message #891186 is a reply to message #890983] Sun, 24 June 2012 08:08 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 26152
Registered: July 2009
Senior Member
Frank,

EMF doesn't currently rely on Java 6. I'm not sure if doing so would be
a bad idea...

In any case, I'd certainly be interested in your solution because it's
an annoying problem and it sounds like a useful approach. Please open a
bugzilla with an outline of your solution, assuming you want to
contribute it as EPL to EMF.


On 23/06/2012 6:57 PM, Missing name Mising name wrote:
> For anyone trying to solve the same problem, this is what I've done.
> Because I need the functionality of my EMF plugins to also be
> available in stand-alone mode, I've used the Java ServiceLoader class
> to do that. (You can find many examples online).
> I've added a "loader" class into each plugin. All it does is
> initializing the EMF package.
> Then I've used the Java ServiceLoader to execute each 'loader' class,
> therefore initializing the contributed packages.
>
> I'm not claiming this is the best approach but in my case it has
> resulted in a clean working solution.
>
> Regards,
> Frank
Java 5 or 6 or7 [message #891226 is a reply to message #891186] Sun, 24 June 2012 11:07 Go to previous message
Ed Willink is currently offline Ed Willink
Messages: 4110
Registered: July 2009
Senior Member
Hi Ed

In the "Contributing extended models in Eclipse and as stand-alone EMF."
thread you wrote
> EMF doesn't currently rely on Java 6. I'm not sure if doing so would
> be a bad idea...
EMF sets the precedent for the rest of Eclipse Modeling. Java 5 has been
convenient for many years now. But JDT has started to impose some Java 6
requirements.

For OCL, https://bugs.eclipse.org/bugs/show_bug.cgi?id=343286 highlights
the benefit of the Java 7 concurrency API. This may remain a pending
enhancement until EMF moves to Java 7.

With Java now moving again with 8 and 9 plans, and with 6 reaching EOL
before Kepler, is it time to move to Java 7 minimum for Kepler?

Regards

Ed Willink
Previous Topic:Using refactoring participants with EMF
Next Topic:[CDO] CDOQuery / SessionManager memory leak?
Goto Forum:
  


Current Time: Fri Oct 31 07:11:21 GMT 2014

Powered by FUDForum. Page generated in 0.01911 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software