Hello,
A
proposition for the new Papyrus architecture has been
committed on the SVN :
trunk/doc/DevelopperDocuments/architecture/refactoring/org.eclipse.papyrus.dev.refactoring
Bug
359058: [Refactoring - Architecture] Identify the layers and
sub-layers for the Papyrus architecture
https://bugs.eclipse.org/bugs/show_bug.cgi?id=359058
Basically,
we have tried to identify where each plug-in *should*
be located, and the dependencies it *should* have
(For example, the plug-in “oep.core”, located in the
“infra/core” layer, currently depends on GMF, although the
“infra/core” layer itself has no dependency over
“infra/gmf”. This means that this plug-in needs to be
refactored, in order to remove this dependency).
You
can still add your comments and suggestions until Friday
21th October.
On
Monday, we will block the commits on the *trunk*, and
create the folders corresponding to the layers (Or a subset
of the layers). The plug-ins will be moved to the SVN Folder
corresponding to their layer, and renamed accordingly. Some
plug-ins will be moved to the deprecated folder.
Afterward,
you will be able to commit again on the trunk (This should
take a few hours).
The
task will then be to clean the plug-in contents, in order to
match the theoretical dependencies between the layers. In
the previous example, we will have to remove the dependency
from oep.core to oep.commands.
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
