Hi Tristan,
an additional remark: on the EObject level, references to imported
models appear in the eCrossReference list. I just wanted to remark that
I initially thought that the resources belonging to cross-referenced
objects were not part of the resource set, since I did not see them
immediately after loading with the debugger - until I realized that the
cross-references were pointing to proxy object's that were resolved on
demand and the resources appear in this moment. I did not make any
changes in the on-demand policy, it was primarly a remark that I had
not been aware initially that referenced models appear in the resource
set. The fact that they appear once resolved made the task a lot
simpler.
Currently, I explicitly unload resources of referenced models if the
underlying OS resource (File) has changed. Thus, the referenced objects
become proxys again and will be resolved on demand (by the existing,
unmodified on-demand load mechanism) with the updated contents.
Ansgar
On 10/05/2010 11:19 AM, GERARD Sebastien 166342 wrote:
Hi Tristan,
By UML imports, Ansgar refers to ElementImport and PackageImport of UML. These concepts are two standard concept of UML2 in order to model import in a UML model in standard way. See the spec respectively on pages 66 and 113.
Best... Sébastien.
-----Message d'origine-----
De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de Tristan FAURE
Envoyé : mardi 5 octobre 2010 11:13
À : Papyrus Project list
Objet : Re: [mdt-papyrus.dev] Automatic reload of models (if underlying resources change)
Hi ansgar some remarks for the 1)
Le 04/10/2010 10:11, Ansgar Radermacher a écrit :
Dear all,
I have checked in a solution for the reload. It supports the reload of
the model that is edited (tool asks user if he wants to reload) and of
imports (are unloaded automatically without user intervention, will
reload the new contents on demand). In the moment, there are no
additional mechanism for preventing the user from simultaneous editing
which would be important in the context of multiple users working on
the same resource (and which would require quite different mechanisms
of opening models, probably not file-based).
1. The observation/tests seemed to indicate that the resource set does
not contains UML imports and tried to figure out how to detect imports
without writing UML specific code ... until I found out that imports
are indeed part of the resource set, but do not appear until the
imports are actually loaded (proxy resolution). Although I was in
principal aware of the "on-demand" loading policy, I thought resources
would always be created but only load on demand (resource have an
"isLoaded" flag). I added a comment to the model set to clarify this issue.
I don't understand what you mean by UML Imports ? I reckon UML Imports are all the resources loaded by the resources except the first one.
Did you check the code of OnDemandLoadingModelSet which is in charge to load resources according to user defined strategy ?
If you see the code you can remark that we have currently in Papyrus the control of Resource Loading and you extend the behavior to manage which resources are loaded or not ?
Concerning the isLoaded flag if i remember it is used if the resource has been loaded using Tracking_modification parameter.
2. I had a strange behavior with regards to imports: the model
explorer updated these correctly, when I used an Eclipse text editor
for the imported model (e.g. changed a class name), but not when I
changed the name with an external editor+executed a refresh with the
navigator. The simple reason for the different behavior: In my case,
the navigator and model explorer share the same panel, i.e. only one
of same is visible at a given time: when I call refresh, the explorer is temporarly invisible.
The problem is (see bug 326851) that the model explorer does not
perform refresh operations when not visible which is an issue independ
of automatic reloads. As a quick workaround, the refreshs are always enabled.
Best regards
Ansgar
On 09/24/2010 12:10 PM, Vincent Hémery wrote:
Hello,
We have developped a feature which is very close to this in Topcased.
There are two different approaches, but I do not know whether the
second one is feasable :
1. Use the same one as on Topcased, with each editor using a
different
2. Use a common editing domain to share the resource whithin the
different editors. In such a case, changes made in one editor will be
repercuted on all editors, without having to reaload anything. All
conflict problems will be (almost magically) solved.
The main problem is that normally, having one editing domain also
means having only one command stack. And we would prefer keep
separated command stacks within each editor.
On Topcased, we have chosen the 1st approach. So I can give you more
details about it :
In such a context, I think your approach of tracking resources
changes is the correct one. It is the same one as we applied on Topcased.
My advice is to keep a list of resources which have been modified to
reload them only when it is necessary.
The main problematic is that giving write access to every editor will
cause conflicts on resources.
Hence, you will have two options :
A. Detect when these conflicts may occur and open only one editor
in write mode by group of ModelSet sharing a same Model.
This approach allows to minimize the number of reload, which may
cost a lot of time.
B. Reload at each modification as suggested in the bug. The problem
is that if you edit with two conflicting editors, you will keep
always refreshing the editors before each modification.
In Topcased, we've chosen approach A.
If you want to perform a refresh at each time the editor gets the
focus, you can perform it with a listener with the following code on
the editor :
PartListenerAdapter listener;
getSite().getPage().addPartListener(listener);
Though, I think authorizing conflicting editors working on the same
resources is a bad idea. On the other hand, you can use it to perform
other tasks, such as a check of read-only files.
While I'm talking about the write access of editors (hence about
editors in read-only), I do not know either how files with the
read-only attribute have been handled in Papyrus.
This will most probably happen when users use files shared with SVN,
with a lock policy making all file read-only by default.
In such conditions, it would be a good thing if Papyrus forbides to
edit the read-only files in the editor.
Another point which you should be aware of : there are resource
loading mechanisms which already exist on Papyrus. Have a look on the
org.eclipse.papyrus.core.resourceloading plugin.
You may have to use them or they may impose you some restrictions.
This is a vast task you are beginning. You may contact me if you have
other interrogations.
Best regards,
Vincent.
Regards
Tristan FAURE
_______________________________________________
mdt-papyrus.dev mailing list
mdt-papyrus.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev
--
Ansgar Radermacher CEA/DRT/DILS/LISE
http://www-list.cea.fr/index.htm
http://www2.cs.unibw.de/alumni/Ansgar/
phone: +33 16908 3812
mailto: ansgar.radermacher@xxxxxx
|
