| Re: [mdt-papyrus.dev] Papyrus refactoring |
|
Hello, I’d like to raise a few issues regarding the current architecture/implementation: -
Icons: In a few Papyrus Activators, we have a method to retrieve the images in a plug-in. The problem is that this method can hardly be reused, as it would imply a dependency on the plug-in
which provides it (Namely, oep.diagram.common). Consequently, we often have to duplicate this method. -
It can be hard to retrieve an icon when we want to reuse an existing one
o
Suggestion: add a plug-in for managing the icons, containing the tools for retrieving an Image/ImageDescriptor, and a set of domain/technology-independent icons (i.e. the Papyrus logo,
some generic images related to the widgets, …)
o
These icons’ path should be accessible through a Java constant (It could be useful to change the Papyrus logo from gif to png without having to edit all plug-ins)
o
The domain-specific icons (i.e. the UML Metamodel icons) should remain in the *.edit plug-in (They are handled by EMF) -
We need a new layer (or sub-layer) between the eclipse implementation of UML, and our GMF-dependent diagrams, which can be reused outside of the diagrams (For example in the property view/model
explorer, when the diagram is closed)
o
It should contain the following tools:
§
Refactoring methods
§
Label providers/Content providers (This is specific to JFace/SWT, but I’m not sure this is a problem yet). Currently, we have tons of classes or methods to retrieve a label for an element…
§
Comparators
§
…
o
We have added some annotations to the UML Models (icon’s _expression_ for a stereotype icon, …), but I’m not sure we really know what has been added and why. We should clearly identify these
cases. -
We need a new plug-in for EMF tools:
o
Label/Content providers
o
Comparators
o
… -
In most tools, we rely a lot on EMF Facet (Queries/UICustom/Facets, used by the Property view, Model Explorer, Tables…). It seems difficult to avoid this dependency. Is it a problem to
have this dependency in the infrastructure layer of Papyrus? Camille De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx]
De la part de LETAVERNIER Camille Hello, In prevision of the next version of Papyrus (0.9.0, based on Juno), we plan to do a global refactoring of the Papyrus architecture. The base architecture is not clear anymore, and some plug-ins have become really messy.
It is hard to distribute Papyrus in distinct features, as most plug-ins are inter-related. Before doing this refactoring, we want to open the discussion to the Mailing List, so that everyone knows what’s going to happen, when, and how. So, here are the main lines : -
Papyrus architecture :
o
Identify the different architecture layers and sub-layers
o
Associate each plug-in to a layer. This may require to split or merge some plug-ins -
Papyrus SVN :
o
Map the svn folders to the Papyrus layers (Each folder should represent either a layer or a sub-layer)
o
Clean the svn, by moving the deprecated plug-ins and code to the deprecated folder -
Papyrus Build :
o
Associate the main layers or sub-layers to a distributable feature These tasks will take time, and each developer will have to be aware of the process. Here are the actual tasks : Preparation : -
Commit your current developments ; it will be harder when the refactoring has started
o
Add a documentation to each plug-in : we ask all developers to add a document file to their own plug-ins (Bug 359060)
o
Determine the format of the documentation file (Text file, EMF Model, is there an existing format ?) : This should be done quickly (This week if possible). The format can be improved later on. (Bug 359061) -
Identify the architecture layers and sub-layers (Bug 359058) -
Associate each plug-in to the corresponding layer, and check the resulting dependencies.
o
Adjust the plug-ins contents until the dependencies match the architecture -
Specify the maximum length of a plug-in file’s qualified name (Plug-in name + path to the file) Actual refactoring : -
Rename the plug-ins or packages which name is longer than the specified max length -
Rename the folders on the SVN to match the layers and sublayers (Bug 359063) -
Create a feature for each layer -
Move the plug-ins to the SVN folder corresponding to their layer -
Add the plug-ins to the feature corresponding to their layer The preparation should take between one and two weeks. The actual refactoring will start in two weeks. Some tasks can be done quickly (Reorganization), but there are two other tasks, more complex, which will take more
time : the ModelSet re-specification, and the access to the “current” model without calling the active Papyrus Editor. They will be discussed in another e-mail. The global Bugzilla task for the whole refactoring is here : 359057: [Architecture - SVN - Build] The Papyrus architecture should be refactored https://bugs.eclipse.org/bugs/show_bug.cgi?id=359057 Do not hesitate to add subtasks for all refactoring-related tasks (Even for local refactorings, which only impact your own plug-ins) Camille |