Hello,
I
come back to the plug-in documentation format :
359061:
[Refactoring] Define a standard plug-in documentation format
https://bugs.eclipse.org/bugs/show_bug.cgi?id=359061
As
far as I know, there is no mechanism in Eclipse to add
documentation to a plug-in. There are a few properties in
the Manifest (Provider, Name, and description), but the
description doesn’t seem to be actually used by the platform
anyway ; and we need more information (Especially regarding
the “implicit dependencies”, which are not Java
dependencies).
Does
anyone know about such a mechanism in Eclipse ? (E3, E4 ?)
We’ve thought about the “package Javadoc” mechanism, but
some plug-ins are not java-based (Model contribution, …)
So,
we have two solutions left :
-
A simple text (or
*.properties) file
-
An EMF Model
Unless
a standard mechanism exists in Eclipse, the EMF Model seems
to be the best approach. This only requires an EMF editor at
development time (Although the generic EMF editor is not the
best tool to edit the multiline comments…), and can be
easily manipulated by custom tools. It is also easier to
structure than a *.properties file, and we can add generic
properties to the metamodel to allow some flexibility.
I’ve
attached an Ecore metamodel and a sample model. Do not
hesitate to comment them, and propose new fields if
necessary. Please check the original requirements on the
bugzilla for more information.
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