Home » Modeling » Papyrus » Relationship of Editors to Resource Sets
| Relationship of Editors to Resource Sets [message #922063] |
Mon, 24 September 2012 17:50  |
|
Hi,
In the Juno release, each Papyrus editor creates a resource set
(ModelSet) for itself, with its own editing domain (a transactional
kind). All of the diagrams within the editor share this resource set,
and it is shared also with other views such as the Model Explorer and
the Properties view.
In a UML model, I can use the "Import Package from Workspace" action in
the Model Explorer to import a package from another UML model. This
lets me edit that model in the context of the importing model. Now, I
might also have that model open in its own editor, or possibly even
imported into other models. As a result, this imported model may be
loaded several times in different resource sets. Saving changes in one
editor might clash with changes pending in other editors, and the
conflict can only be resolved by discarding changes from all editors
but one and re-loading them from disk. This is fine, and consistent
with standard editor workflows in Eclipse.
However, this particular problem in cross-referenced models wouldn't
happen if all of the Papyrus editors shared a single resource set
(ModelSet), but maybe that would cause other issues. I looked through
the design documentation on the Wiki and in SVN, but didn't find a
discussion of why the decision to implement per-editor resource sets
versus a single shared resource set was made.
Could somebody point me to any document(s) that discuss(es) this
question, or perhaps explain briefly here why Papyrus editors maintain
distinct resource sets? I would like to know to better understand the
implications of enhancing Papyrus to access models in a CDO repository,
where the delineation of "models" and "resources" is less clear than it
is in the workspace. It would be nice to find a way to make the
management of resources consistent in both the workspace and the
repository, which might entail revisiting the way they are managed in
the workspace.
Thanks,
Christian
|
|
|
| Re: Relationship of Editors to Resource Sets [message #930467 is a reply to message #922063] |
Tue, 02 October 2012 10:42  |
 Cedric Dumoulin
Messages: 51
Registered: July 2009 |
Member |
|
|
Hi Christian,
In Papyrus, we have choose to clearly separate each editor. It is why we
have used one ResourceSet for each editor.
We have do that because we want to avoid that all open Papyrus editors
crash in the case of one of them crash. User will certainly not
understand such a behavior :-).
You are right that this choice as some drawback when a "model" is shared
and edited in several editors. Maybe we need to add a mechanism to
listen on modification on the persistence storage (ie files).
From the implementation point of view, we use the ResourceSet and
Resource as a link to the persistence storage, also to listen for
modifications on the editor's models, and to associate one
"DomainEditor" per Papyrus editor.
We have introduce the classes ModelSet and Model, which is an attempt to
provide a higher level API to manipulate models regardless of how they
are persisted. Actually, the persistence of models is implemented by
ResourceSet and Resources.
The work on ModelSet and Model is not finished yet, and we are open to
any suggestion for enhancement. It could be great if we found a solution
allowing to use both CDO and emf ResourceSet, and why not any other
persistence storage mechanism.
I am open to any discussion on this topic.
Cedric
Christian W. Damus a écrit :
> Hi,
>
> In the Juno release, each Papyrus editor creates a resource set
> (ModelSet) for itself, with its own editing domain (a transactional
> kind). All of the diagrams within the editor share this resource set,
> and it is shared also with other views such as the Model Explorer and
> the Properties view.
>
> In a UML model, I can use the "Import Package from Workspace" action in
> the Model Explorer to import a package from another UML model. This
> lets me edit that model in the context of the importing model. Now, I
> might also have that model open in its own editor, or possibly even
> imported into other models. As a result, this imported model may be
> loaded several times in different resource sets. Saving changes in one
> editor might clash with changes pending in other editors, and the
> conflict can only be resolved by discarding changes from all editors but
> one and re-loading them from disk. This is fine, and consistent with
> standard editor workflows in Eclipse.
>
> However, this particular problem in cross-referenced models wouldn't
> happen if all of the Papyrus editors shared a single resource set
> (ModelSet), but maybe that would cause other issues. I looked through
> the design documentation on the Wiki and in SVN, but didn't find a
> discussion of why the decision to implement per-editor resource sets
> versus a single shared resource set was made.
>
> Could somebody point me to any document(s) that discuss(es) this
> question, or perhaps explain briefly here why Papyrus editors maintain
> distinct resource sets? I would like to know to better understand the
> implications of enhancing Papyrus to access models in a CDO repository,
> where the delineation of "models" and "resources" is less clear than it
> is in the workspace. It would be nice to find a way to make the
> management of resources consistent in both the workspace and the
> repository, which might entail revisiting the way they are managed in
> the workspace.
>
> Thanks,
>
> Christian
>
|
|
|
| Re: Relationship of Editors to Resource Sets [message #930998 is a reply to message #930467] |
Tue, 02 October 2012 20:50 |
|
Hi, Cedric,
Thanks for your reply! I'm glad to hear from you.
See some responses in-line, below.
Thanks,
Christian
On 2012-10-02 10:42:19 +0000, Cedric Dumoulin said:
> Hi Christian,
>
> In Papyrus, we have choose to clearly separate each editor. It is why
> we have used one ResourceSet for each editor.
>
> We have do that because we want to avoid that all open Papyrus editors
> crash in the case of one of them crash. User will certainly not
> understand such a behavior :-).
What kind of a crash are you referring to? When I think of "crash",
it's usually the entire Eclipse workbench failing that comes to mind.
> You are right that this choice as some drawback when a "model" is
> shared and edited in several editors. Maybe we need to add a mechanism
> to listen on modification on the persistence storage (ie files).
There is already a listener that detects changes in the underlying file
in some cases, but not all. For example, if I edit a package in one
editor and a package that imports the first package in another editor,
if I modify the imported package in the second editor and save, then
the first editor complains that its model file has changed.
However, if I open an editor on a controlled package and another editor
on its parent package, then modify the controlled package in this
second editor and save, the first editor (on the controlled package)
doesn't know that anything has happened.
> From the implementation point of view, we use the ResourceSet and
> Resource as a link to the persistence storage, also to listen for
> modifications on the editor's models, and to associate one
> "DomainEditor" per Papyrus editor.
> We have introduce the classes ModelSet and Model, which is an attempt
> to provide a higher level API to manipulate models regardless of how
> they are persisted. Actually, the persistence of models is implemented
> by ResourceSet and Resources.
Yes, I have become quite familiar with the ModelSet and IModel in my
analysis of what would be required to support storing Papyrus models in
CDO repositories. :-) The tie-in to pluggable services is a nice
abstraction.
> The work on ModelSet and Model is not finished yet, and we are open to
> any suggestion for enhancement. It could be great if we found a
> solution allowing to use both CDO and emf ResourceSet, and why not any
> other persistence storage mechanism.
Yes, as I mentioned, I am working through a fairly detailed
design/analysis of porting Papyrus onto CDO. As it happens, CDO's
support for object-level locking and for detecting and resolving
conflicts (dirty writes) at the object level should help to alleviate
some of the issues with multiple resource sets editing the same
resource.
> I am open to any discussion on this topic.
Thanks. For now, what I needed most to know was the intention behind
the current architecture, to better understand what kinds of changes
(if any) to propose for an integration of CDO, because I don't have the
background knowledge of what requirements or problems informed the
design. I will probably have more questions down the road.
> Cedric
>
>
>
> Christian W. Damus a écrit :
>> Hi,
>>
>> In the Juno release, each Papyrus editor creates a resource set
>> (ModelSet) for itself, with its own editing domain (a transactional
>> kind). All of the diagrams within the editor share this resource set,
>> and it is shared also with other views such as the Model Explorer and
>> the Properties view.
>>
>> In a UML model, I can use the "Import Package from Workspace" action in
>> the Model Explorer to import a package from another UML model. This
>> lets me edit that model in the context of the importing model. Now, I
>> might also have that model open in its own editor, or possibly even
>> imported into other models. As a result, this imported model may be
>> loaded several times in different resource sets. Saving changes in one
>> editor might clash with changes pending in other editors, and the
>> conflict can only be resolved by discarding changes from all editors but
>> one and re-loading them from disk. This is fine, and consistent with
>> standard editor workflows in Eclipse.
>>
>> However, this particular problem in cross-referenced models wouldn't
>> happen if all of the Papyrus editors shared a single resource set
>> (ModelSet), but maybe that would cause other issues. I looked through
>> the design documentation on the Wiki and in SVN, but didn't find a
>> discussion of why the decision to implement per-editor resource sets
>> versus a single shared resource set was made.
>>
>> Could somebody point me to any document(s) that discuss(es) this
>> question, or perhaps explain briefly here why Papyrus editors maintain
>> distinct resource sets? I would like to know to better understand the
>> implications of enhancing Papyrus to access models in a CDO repository,
>> where the delineation of "models" and "resources" is less clear than it
>> is in the workspace. It would be nice to find a way to make the
>> management of resources consistent in both the workspace and the
>> repository, which might entail revisiting the way they are managed in
>> the workspace.
>>
>> Thanks,
>>
>> Christian
|
|
|
| Re: Relationship of Editors to Resource Sets [message #937928 is a reply to message #930998] |
Tue, 09 October 2012 11:39 |
Cedric Dumoulin
Messages: 51
Registered: July 2009 |
Member |
|
|
Christian W. Damus a écrit :
>
>>
>> In Papyrus, we have choose to clearly separate each editor. It is why
>> we have used one ResourceSet for each editor.
>>
>> We have do that because we want to avoid that all open Papyrus editors
>> crash in the case of one of them crash. User will certainly not
>> understand such a behavior :-).
>
> What kind of a crash are you referring to? When I think of "crash",
> it's usually the entire Eclipse workbench failing that comes to mind.
Sometime something wrong happen in the models. This often happen when
the user do a lot of delete. I suspect that some classes became orphan,
or that some links get broken. This can lead to Editor malfunctions or
crash. If all editor share the same ResourceSet, I suspect that we can
have side effect on other editors.
>
>
>> You are right that this choice as some drawback when a "model" is
>> shared and edited in several editors. Maybe we need to add a mechanism
>> to listen on modification on the persistence storage (ie files).
>
> There is already a listener that detects changes in the underlying file
> in some cases, but not all. For example, if I edit a package in one
> editor and a package that imports the first package in another editor,
> if I modify the imported package in the second editor and save, then the
> first editor complains that its model file has changed.
>
> However, if I open an editor on a controlled package and another editor
> on its parent package, then modify the controlled package in this second
> editor and save, the first editor (on the controlled package) doesn't
> know that anything has happened.
>
>
>> From the implementation point of view, we use the ResourceSet and
>> Resource as a link to the persistence storage, also to listen for
>> modifications on the editor's models, and to associate one
>> "DomainEditor" per Papyrus editor.
>> We have introduce the classes ModelSet and Model, which is an attempt
>> to provide a higher level API to manipulate models regardless of how
>> they are persisted. Actually, the persistence of models is implemented
>> by ResourceSet and Resources.
>
> Yes, I have become quite familiar with the ModelSet and IModel in my
> analysis of what would be required to support storing Papyrus models in
> CDO repositories. :-) The tie-in to pluggable services is a nice
> abstraction.
>
>
>> The work on ModelSet and Model is not finished yet, and we are open to
>> any suggestion for enhancement. It could be great if we found a
>> solution allowing to use both CDO and emf ResourceSet, and why not any
>> other persistence storage mechanism.
>
> Yes, as I mentioned, I am working through a fairly detailed
> design/analysis of porting Papyrus onto CDO. As it happens, CDO's
> support for object-level locking and for detecting and resolving
> conflicts (dirty writes) at the object level should help to alleviate
> some of the issues with multiple resource sets editing the same resource.
>
>
>> I am open to any discussion on this topic.
>
> Thanks. For now, what I needed most to know was the intention behind
> the current architecture, to better understand what kinds of changes (if
> any) to propose for an integration of CDO, because I don't have the
> background knowledge of what requirements or problems informed the
> design. I will probably have more questions down the road.
My intention is to be able to save Models in any kind of persistence
repository, be file, CDO or other.
Unfortunately, The Model and ModelSet framework is not complete, and
I suspect that it is sometime by-passed in the code.
One goal is to be able to use the native ResourceSet mechanism, as
well as CDO or other.
The architecture guideline is to have a set of services that can be
replaced. Once of them could be the "persistence services" ...
Cedric
>
>
>>
|
|
|
Goto Forum:
Current Time: Thu Apr 25 19:32:34 GMT 2024
Powered by FUDForum. Page generated in 0.03548 seconds |
] 
Search
Help
Register
Login
Home
