Home » Modeling » EMF » Registering with package registry manually
| |
| Re: Registering with package registry manually [message #424537 is a reply to message #424521] |
Wed, 29 October 2008 17:58   |
 Cameron Bateman
Messages: 481
Registered: July 2009 |
Senior Member |
|
|
> EPacakge.Registry.INSTANCE.put? Given it's a global singleton,
> modification is a bit scary.
I have been meaning to ask about that. Is that guy thread-safe? I notice
there is an extension point provided to contribute a custom implementation
of the registry...
> My wires are crossed now. A generated package does no good until that
...
> you can use Load Resource... to refer to it anywhere else in the workspace
Sorry, I should have been more specific. I have an ecore model called
"base.ecore" which I have also generated the code for. Then I have a
CodeGenerator that creates a second ecore model in the same workspace as
base (so as you say, there's no way for the generated_package ext-pt to
help me). When I serialize my generated model, references to eClasses in
base look like this:
<eSuperTypes href="http://com.oracle/base#//AbstractSuperClass"/>
where "http://com.oracle/base" is the package uri for base and
AbstractSuperClass is the eSuperType. To serialize I use:
XMLResource outputRes = new XMLResourceImpl();
outputRes.getContents().add(epackage);
outputRes.save(outstream, Collections.EMPTY_MAP);
where epackage is the instance of EPackage that I have constructed.
Now, when I open the ecore model in the "Sample Ecore Model Editor", for
each sub-class I see in the tree it says:
MySubclass -> null
and the problems tab doesn't open.
If I do a "Load Resource..." and add base.ecore to the editor, it loads
fine, but the super-type still doesn't resolve. If I manually change the
eSuperType to the one from the loaded resource, this works, but now the
model serializes as:
eSuperTypes="base.ecore#//AbstractSuperClass"
I'm pretty sure this is not what I want, since I have lost the encoding of
base's uri, so I have split the two files into two locations, how would
base every get resolved through the package registry?
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=220218 as well...
The use case seems similar. But if I manually load the ecore as resource,
I'm still not clear why this doesn't resolve based on the package uri.
> BTW #eclipse-modeling is a good way to have a live discussion...
On the Eclipse IRC chat forum? Cool, I look into it.
Thanks,
Cameron
|
|
|
| Re: Registering with package registry manually [message #424539 is a reply to message #424537] |
Wed, 29 October 2008 18:55 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Cameron,
Comments below.
Cameron Bateman wrote:
>> EPacakge.Registry.INSTANCE.put? Given it's a global singleton,
>> modification is a bit scary.
>
> I have been meaning to ask about that. Is that guy thread-safe? I
> notice there is an extension point provided to contribute a custom
> implementation of the registry...
It's populated during startup by registration and the conversion from
Descriptor to actual EPackage shouldn't cause a problem because it's
guarded by static initialization. But adding to it from multiple
threads directly via code is not a good idea.
>
>> My wires are crossed now. A generated package does no good until that
> ..
>> you can use Load Resource... to refer to it anywhere else in the
>> workspace
>
> Sorry, I should have been more specific. I have an ecore model called
> "base.ecore" which I have also generated the code for. Then I have a
> CodeGenerator that creates a second ecore model in the same workspace
> as base (so as you say, there's no way for the generated_package
> ext-pt to help me). When I serialize my generated model, references
> to eClasses in base look like this:
>
> <eSuperTypes href="http://com.oracle/base#//AbstractSuperClass"/>
So that's via the nsURI, which hints that the are references to the
generated XyzPackage.eINSTANCE, right?
>
> where "http://com.oracle/base" is the package uri for base and
> AbstractSuperClass is the eSuperType. To serialize I use:
>
> XMLResource outputRes = new XMLResourceImpl();
Newing up resources directly is usually a bad sign. You ought to be
using resource factories to create your resources. There's
EcoreResourceFactoryImpl, for example. And generally I'd expect you to
use a resource set's createResource method...
> outputRes.getContents().add(epackage);
> outputRes.save(outstream, Collections.EMPTY_MAP);
Relative references are going to cause you problems as well. I'm
surprised the null URI on the resource isn't breaking things...
>
> where epackage is the instance of EPackage that I have constructed.
>
> Now, when I open the ecore model in the "Sample Ecore Model Editor",
> for each sub-class I see in the tree it says:
>
> MySubclass -> null
>
> and the problems tab doesn't open.
You really need to be using resource sets. All your objects should be
in resources, and the URIs used to reference will be impacted by those.
>
> If I do a "Load Resource..." and add base.ecore to the editor, it
> loads fine, but the super-type still doesn't resolve.
In the Ecore editor, this will load that other resource into the same
resource set.
> If I manually change the eSuperType to the one from the loaded
> resource, this works, but now the model serializes as:
>
> eSuperTypes="base.ecore#//AbstractSuperClass"
And that other resource I can tell was in the same folder so you ended
up with a nice relative reference to it.
>
> I'm pretty sure this is not what I want, since I have lost the
> encoding of base's uri, so I have split the two files into two
> locations, how would base every get resolved through the package
> registry?
Oh, so many questions and so many times I've explained it to so many
people. :-(
>
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=220218 as well...
>
> The use case seems similar. But if I manually load the ecore as
> resource, I'm still not clear why this doesn't resolve based on the
> package uri.
In that bugzilla you'll see I explain complicated things, like the fact
that a package can exist in many forms. In the installed IDE you'll
have XyzPackage.eINSTANCE; if you refer to that, it will use the nsURI
because XyzPackage.eINSTANCE.eResource().getURI() is the same as the
nsURI. There's also likely to be
platform:/plugin/<xyz>/model/Xyz.ecore. That's the serialized
development time instance in the binary plugin. If you have this plugin
in your workspace, you'll also have
platform:/resource/<xyz>/model/Xyz.ecore. Yet a third version of it.
This doesn't even bring the target platform into the picture, where
there might be yet another version.
Generally within the workspace, you should be using
platform:/resource/<project>/model/Xyz.ecore for all your Ecore models.
All references will be relative as a result. So you'll see base.ecore,
or ../../other.project/model/base.ecore. When you read a resource with
a relative URI, the URI is made absolute relative to the document
containing the reference (just like what happens in HTML href="...").
This means that if you load the resource with
platform:/plugin/<plugin-id>/model/Xyz.ecore, all the relative
references will resolve to be platform:/plugin/..., i.e., they'll all be
in the running IDE's plugin space. If you load with
platform:/resource/<project-name>/model/Xyz.ecore, then all relative
references will resolve to be platform:/resource/..., i.e., they'll all
be in the workspace.
So generally you should be making sure your development time versions
are in the workspace and refer to each other via relative paths. As if
that's not all complicated enough...
We also do this in the EcoreEditor, GenModelEditor, and anywhere we work
with the GenModel:
editingDomain.getResourceSet().getURIConverter().getURIMap() .putAll(EcorePlugin.computePlatformURIMap());
This makes registered serialized Ecore models in the IDE look like they
exist as projects in the workspace so that you can refer to them in that
fashion.
I could go on and on, but I don't really understand what you are doing,
but that it's not being done quite right and getting it right requires
understanding quite a few complex things...
>
>> BTW #eclipse-modeling is a good way to have a live discussion...
>
> On the Eclipse IRC chat forum?
Yes.
> Cool, I look into it.
I can skype you as well, since I suspect a conversation would go faster.
>
>
> Thanks,
>
> Cameron
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| Re: Registering with package registry manually [message #424570 is a reply to message #424563] |
Thu, 30 October 2008 10:24 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Cameron,
Thanks for the interesting recipe! One thing you might find interesting
in your scenario is EReference.eKeys. You've made "id" be an EAttribute
with isID true, which is perfectly fine, but you could also have left it
as an ordinary attribute and made "id" be an eKey of the Custoner.rows
EReference. In this case, the ID only has to be unique within a given
CustomerTable instance, not unique within the whole containing resource
(even across different types of objects). I only mention it because it
seems a closer match to the notion of a key in a table, and because your
recipe is very help and I appreciate that a lot...
As you've discovered too, what's so nice about relative URIs is it
hides/omits the information about what form of absolute URI was used to
create the files. As long as you move the files as a group, they can be
referenced by any absolute scheme and all resolve properly.
Cameron Bateman wrote:
>> So that's via the nsURI, which hints that the are references to the
>> generated XyzPackage.eINSTANCE, right?
>
> Yeah, that was exactly the problem. I shouldn't have been using
> eINSTANCE's on models that weren't registered via plugin.
> I have added a recipe at the URL below that hopefully captured most of
> what I've learned here:
>
> http://wiki.eclipse.org/EMF/Recipes#Recipe:_Generating_Your_ Own_Ecore_Model_using_a_stand-alone_Java_App
>
>
> Note, that I have used file uri's instead of platform ones because I'm
> handling the case of a standalone tool (easier to bootstrap than
> trying to write my own generator on the first try). This still seems
> to work fine if the generator output is then manually copied into an
> Eclipse project file since the paths are encoded relative so the
> specific uri schema doesn't appear to come into play (file:/ vs.
> platform:/).
>
>
> Thanks,
>
> Cameron
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Thu Apr 25 13:26:43 GMT 2024
Powered by FUDForum. Page generated in 0.03270 seconds |
] 
Search
Help
Register
Login
Home
