Home » Modeling » EMF » EMF package registry inside Eclipse?
| EMF package registry inside Eclipse? [message #431267] |
Tue, 07 July 2009 07:03  |
Eclipse User |
|
|
|
Originally posted by: hoe.zurich.ibm.com
I am looking for best practices in the following situation:
I have an EMF model defined in a plug-in project in the Eclipse
workspace. As such, it includes extensions that plug into
org.eclipse.emf.ecore.generated_package, and so its packages will become
registered e.g. after Run As / Eclipse Application.
However, what I want to do now is also use the EMF model in the context
of the development environment (i.e. prior to Run As / Eclipse
Application). Specifically what I have in mind is its use with the
Eclipse BIRT Report Designer (for an EMF Data Source that's included in
IBM's RSA 7.5, but that should be of no concern here).
Currently this does not work, and I think it's because the model's
packages are not yet properly registered from the tool's point of view.
I do know how I could register them programatically, but what to do in
the case of an existing tool inside Eclipse? Is there such a thing as
Eclipse's own EMF package registry that I could access under
Preferences, or similar?
I have a simple work-around: applying the tool in a runtime (not
development) context, i.e. after Run As / Eclipse Applications, but it
has several obvious drawbacks, so I hope to improve on it.
Thanks for your help,
Christian
|
|
|
| Re: EMF package registry inside Eclipse? [message #431272 is a reply to message #431267] |
Tue, 07 July 2009 09:11  |
 Ed Merks
Messages: 33133
Registered: July 2009 |
Senior Member |
|
|
Christian,
Comments below.
Christian Hoertnagl wrote:
> I am looking for best practices in the following situation:
>
> I have an EMF model defined in a plug-in project in the Eclipse
> workspace. As such, it includes extensions that plug into
> org.eclipse.emf.ecore.generated_package, and so its packages will
> become registered e.g. after Run As / Eclipse Application.
>
> However, what I want to do now is also use the EMF model in the
> context of the development environment (i.e. prior to Run As / Eclipse
> Application). Specifically what I have in mind is its use with the
> Eclipse BIRT Report Designer (for an EMF Data Source that's included
> in IBM's RSA 7.5, but that should be of no concern here).
>
> Currently this does not work, and I think it's because the model's
> packages are not yet properly registered from the tool's point of view.
What's the symptom of "this not working"?
> I do know how I could register them programatically, but what to do in
> the case of an existing tool inside Eclipse? Is there such a thing as
> Eclipse's own EMF package registry that I could access under
> Preferences, or similar?
Perhaps https://bugs.eclipse.org/bugs/show_bug.cgi?id=220218 is related,
but unfortunately my good intentions to produce good things are
infinitely scalable.
>
> I have a simple work-around: applying the tool in a runtime (not
> development) context, i.e. after Run As / Eclipse Applications, but it
> has several obvious drawbacks, so I hope to improve on it.
Maybe you could be more clear what the problem is. Perhaps it's
related to the fact that your model will only be available if it's
installed in the running IDE or if it's in the workspace. We do not yet
support it being in the target platform, which is an aspect of the
bugzilla I referred to above. So right now an Ecore model can be
referenced as <nsURI>, i.e., the XyzPackage.eINSTANCE registered in the
running IDE/environment,
platform:/plugin/<plugin-id>/<path-to-Ecore-model>, i.e., the
development time version contained in the bundle in the running
IDE/environment, or
platform:/resource/<project-name>/<path-to-Ecore-model>, i.e, a resource
in the workspace. Note also that things like the Sample Ecore Editor
use this trick so that development time versions (URIs) in the
IDE/environment are redirected to the workspace version should one exist:
editingDomain.getResourceSet().getURIConverter().getURIMap() .putAll(EcorePlugin.computePlatformURIMap());
Of course I'm not sure if any of this answer your question because I'm
not sure specifically the problem..
>
> Thanks for your help,
> Christian
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: EMF package registry inside Eclipse? [message #431293 is a reply to message #431272] |
Tue, 07 July 2009 16:56 |
| Eclipse User |
|
|
|
Originally posted by: hoe.zurich.ibm.com
Ed,
Thanks for your quick attention.
Ed Merks wrote:
> What's the symptom of "this not working"?
The symptom is a rather undescriptive error message displayed when
trying to create a Preview on a BIRT report design (with EMF data source
in IBM RSA 7.5). Triaging (including the mentioned work-around) led me
to conclude it's EMF-related.
> A BIRT exception occured.
> Plug-in Provider: Eclipse.org
> Plug-in NameL BIRT Data Engine
> Plug-in ID: org.eclipse.birt.data
> Version: 2.3.0.20080606_rev001
> Error Code:odaconsumer.CannotExecuteStatement
> Error Message: Cannot execute the statement
> Perhaps https://bugs.eclipse.org/bugs/show_bug.cgi?id=220218 is related,
Yes, I do think this is related, although it talks both about URI
conversion and about package registration. My problem is (I think) about
package registration alone. Let me try to rephrase it as follows:
(1) Suppose I have an EMF model defined in a plug-in project in the
Eclipse workspace (with extensions that plugs into
org.eclipse.emf.ecore.generated_package for non-programmatic package
registrations as normal).
(2) Suppose I write a simple test case that loads a Resource from a
local XMI file.
(2a) When I run (2) as JUnit plug-in test, I would expect it to work --
because the said extensions are in place.
(2b) When I run (2) as JUnit test, I would expect it not to work --
because the said extensions are not in place.
(3) Now suppose that I change (2) such that it behaves like a
stand-alone EMF program, i.e. with explicit Resource Factory and Package
registrations.
(3a) When I run (3) as JUnit plug-in test, I would expect it still to work.
(3b) When I run (3) as JUnit test, I would expect it also to work --
because of the explicit registrations.
It seems to me that running a tool such as the BIRT Report Designer in
Eclipse, is a bit similar to the JUnit test situation, in that the tool
does not "see" the plug-in extensions in the workspace (and therefore
does not consider their package registrations). However if I run the
tool in a nested version of Eclipse (entered with Run As / Eclipse
Application), then it's more like the situation with the JUnit plug-in
tests.
Since I cannot possible force the registration programmatically before
a tool is activated inside Eclipse (or change the tool to apply
something like the trick you mentioned), I was wondering if there was
some other/generic way to configure package registrations from inside
the workspace in a situation like this. Maybe there can be none.
I think what currently happens is that the tool can address the model
as platform:/resource/... alright (so it's not a URI conversion issue),
but it then cannot load it (package registration issue) without further
corrective steps.
Again, thanks for your attention -- BACKSPACE BACKSPACE... BACKSPACE --
patience :-)
Christian
|
|
|
| Re: EMF package registry inside Eclipse? [message #431301 is a reply to message #431293] |
Tue, 07 July 2009 21:26 |
Ed Merks
Messages: 33133
Registered: July 2009 |
Senior Member |
|
|
Christian,
Comments below.
Christian Hoertnagl wrote:
> Ed,
>
> Thanks for your quick attention.
>
> Ed Merks wrote:
> > What's the symptom of "this not working"?
>
> The symptom is a rather undescriptive error message displayed when
> trying to create a Preview on a BIRT report design (with EMF data
> source in IBM RSA 7.5). Triaging (including the mentioned work-around)
> led me to conclude it's EMF-related.
>
> > A BIRT exception occured.
> > Plug-in Provider: Eclipse.org
> > Plug-in NameL BIRT Data Engine
> > Plug-in ID: org.eclipse.birt.data
> > Version: 2.3.0.20080606_rev001
> > Error Code:odaconsumer.CannotExecuteStatement
> > Error Message: Cannot execute the statement
>
> > Perhaps https://bugs.eclipse.org/bugs/show_bug.cgi?id=220218 is
> related,
>
> Yes, I do think this is related, although it talks both about URI
> conversion and about package registration. My problem is (I think)
> about package registration alone. Let me try to rephrase it as follows:
>
> (1) Suppose I have an EMF model defined in a plug-in project in
> the Eclipse workspace (with extensions that plugs into
> org.eclipse.emf.ecore.generated_package for non-programmatic package
> registrations as normal).
>
> (2) Suppose I write a simple test case that loads a Resource from
> a local XMI file.
>
> (2a) When I run (2) as JUnit plug-in test, I would expect it to
> work -- because the said extensions are in place.
Yes, me too.
>
> (2b) When I run (2) as JUnit test, I would expect it not to work
> -- because the said extensions are not in place.
Yes, though it might work if something forces the package to be
initialized...
>
> (3) Now suppose that I change (2) such that it behaves like a
> stand-alone EMF program, i.e. with explicit Resource Factory and
> Package registrations.
Yes.
>
> (3a) When I run (3) as JUnit plug-in test, I would expect it still
> to work.
>
> (3b) When I run (3) as JUnit test, I would expect it also to work
> -- because of the explicit registrations.
Sounds like a reasonable assumption.
>
> It seems to me that running a tool such as the BIRT Report
> Designer in Eclipse, is a bit similar to the JUnit test situation, in
> that the tool does not "see" the plug-in extensions in the workspace
> (and therefore does not consider their package registrations). However
> if I run the tool in a nested version of Eclipse (entered with Run As
> / Eclipse Application), then it's more like the situation with the
> JUnit plug-in tests.
Yes, I'm sure it would need to be launched with the model bundles in the
environment.
>
> Since I cannot possible force the registration programmatically
> before a tool is activated inside Eclipse (or change the tool to apply
> something like the trick you mentioned), I was wondering if there was
> some other/generic way to configure package registrations from inside
> the workspace in a situation like this. Maybe there can be none.
No, there can be none. The bundles must be running in the environment...
>
> I think what currently happens is that the tool can address the
> model as platform:/resource/... alright (so it's not a URI conversion
> issue), but it then cannot load it (package registration issue)
> without further corrective steps.
>
> Again, thanks for your attention -- BACKSPACE BACKSPACE... BACKSPACE
> -- patience :-)
Hehehe.
> Christian
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: EMF package registry inside Eclipse? [message #431308 is a reply to message #431301] |
Wed, 08 July 2009 06:35 |
| Eclipse User |
|
|
|
Originally posted by: hoe.zurich.ibm.com
Ed,
Ed Merks wrote:
> No, there can be none. The bundles must be running in the environment...
So that settles it then.
What I can still do is check with the tool designers so see whether
they perhaps have implemented something like the trick. If so, I'll
post about it here for the benefit of this community.
Best regards,
Christian
|
|
| |
| Re: EMF package registry inside Eclipse? [message #431373 is a reply to message #431312] |
Wed, 08 July 2009 09:28 |
Ed Merks
Messages: 33133
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------020104020409060508040209
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Achim,
Comments below.
Achim Demelt wrote:
>> Ed Merks wrote:
>>
>>> No, there can be none. The bundles must be running in the environment...
>>>
>
> I guess we should say "For generated packages, the bundles must be running
> in the environment". In theory, dynamic packages could also be registered
> from inside the workspace. You might imagine a context menu for *.ecore
> files that reads the file and registers the contained EPackages directly
> with the EPackage.Registry in the running workspace.
>
One might imagine it, but it's probably similar to the idea of dynamic
loading classes/bundles. Sure it works, but what happens if the
workspace instance is changed or deleted...
> However, I am not aware of the existence of such a context menu. It would be
> of limited use anyway, since every decent Ecore model is likely to expose
> some behavior, derived properties and validation rules.
Yes, though with some of the bugzillas/patches for specifying these
behaviors directly in the model, this will become far less of a limitation.
> All of which have to
> be coded in Java and must therefore be compiled and running as a bundle in
> your environment.
>
Yes, and in the end, the idea is really no different from dynamically
loading bundles...
> Achim
>
>
--------------020104020409060508040209
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Achim,<br>
<br>
Comments below.<br>
<br>
Achim Demelt wrote:
<blockquote cite="mid:h31ija$cdl$1@build.eclipse.org" type="cite">
<blockquote type="cite">
<pre wrap="">Ed Merks wrote:
</pre>
<blockquote type="cite">
<pre wrap="">No, there can be none. The bundles must be running in the environment...
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
I guess we should say "For generated packages, the bundles must be running
in the environment". In theory, dynamic packages could also be registered
from inside the workspace. You might imagine a context menu for *.ecore
files that reads the file and registers the contained EPackages directly
with the EPackage.Registry in the running workspace.
</pre>
</blockquote>
One might imagine it, but it's probably similar to the idea of dynamic
loading classes/bundles. Sure it works, but what happens if the
workspace instance is changed or deleted...<br>
<blockquote cite="mid:h31ija$cdl$1@build.eclipse.org" type="cite">
<pre wrap="">
However, I am not aware of the existence of such a context menu. It would be
of limited use anyway, since every decent Ecore model is likely to expose
some behavior, derived properties and validation rules.</pre>
</blockquote>
Yes, though with some of the bugzillas/patches for specifying these
behaviors directly in the model, this will become far less of a
limitation.<br>
<blockquote cite="mid:h31ija$cdl$1@build.eclipse.org" type="cite">
<pre wrap=""> All of which have to
be coded in Java and must therefore be compiled and running as a bundle in
your environment.
</pre>
</blockquote>
Yes, and in the end, the idea is really no different from dynamically
loading bundles...<br>
<blockquote cite="mid:h31ija$cdl$1@build.eclipse.org" type="cite">
<pre wrap="">
Achim
</pre>
</blockquote>
</body>
</html>
--------------020104020409060508040209--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| Re: EMF package registry inside Eclipse? [message #431405 is a reply to message #431373] |
Wed, 08 July 2009 11:17 |
Achim Demelt
Messages: 160
Registered: July 2009 |
Senior Member |
|
|
Ed,
Comments below.
Ed Merks wrote:
> Achim,
>
> Comments below.
>
> Achim Demelt wrote:
>>> Ed Merks wrote:
>>>
>>>> No, there can be none. The bundles must be running in the
>>>> environment...
>>>>
>>
>> I guess we should say "For generated packages, the bundles must be
>> running in the environment". In theory, dynamic packages could also be
>> registered from inside the workspace. You might imagine a context menu
>> for *.ecore files that reads the file and registers the contained
>> EPackages directly with the EPackage.Registry in the running workspace.
>>
> One might imagine it, but it's probably similar to the idea of dynamic
> loading classes/bundles. Sure it works, but what happens if the
> workspace instance is changed or deleted...
Yes, this registration would have to listen to changes of the file and re-
register the EPackages. Which will, of course, have unforeseeable
consequences to anyone holding an old copy of the EPackage. Use at your own
risk...
>> However, I am not aware of the existence of such a context menu. It would
>> be of limited use anyway, since every decent Ecore model is likely to
>> expose some behavior, derived properties and validation rules.
> Yes, though with some of the bugzillas/patches for specifying these
> behaviors directly in the model, this will become far less of a
> limitation.
Exactly. One more reason to look forward to these patches :-)
>> All of which have to
>> be coded in Java and must therefore be compiled and running as a bundle
>> in your environment.
>>
> Yes, and in the end, the idea is really no different from dynamically
> loading bundles...
Well, we only load an EPackage, but not a bundle. The OSGi runtime remains
unchanged. But from an EMF point of view, there's not much of a difference.
|
|
|
Goto Forum:
Current Time: Thu Apr 18 06:09:30 GMT 2024
Powered by FUDForum. Page generated in 0.02152 seconds |
] 
Search
Help
Register
Login
Home
