Hello,
A Metamodel of the plug-in documentation has been committed on the trunk/incoming folder :
org.eclipse.papyrus.documentation.plugin
org.eclipse.papyrus.documentation.plugin.edit
org.eclipse.papyrus.documentation.plugin.editor
With these plug-ins, it is possible to define a plug-in document for your plug-ins :
File > New > Example EMF Model Creation Wizards > Documentation Model
Fill in your file name and location, then validate. The important information are the following:
-
Documentation#description: a short description for the plug-in (No more than a few lines, this neither a developer nor a user document)
-
Documentation#reference (New child -> Person): the referent(s) for this plug-in. This is typically the main/current developer(s).
The dependencies property is only used for implicit dependencies (i.e. non-java dependencies, which aren’t always correctly handled by Eclipse). Most of the time, this should remain empty.
Each Papyrus plug-in should contain such a file. It is really important, as it may help us for the refactoring.
You can find an example of documentation files in the following plug-ins:
org.eclipse.papyrus.properties
org.eclipse.papyrus.properties.model
org.eclipse.papyrus.widgets
It would be nice that all plug-ins contain this file for the next week (Friday, October 7); or at the very least, the ones which role isn’t obvious.
Corresponding Bugzilla task:
359060: [Refactoring] All plug-ins should be documented
https://bugs.eclipse.org/bugs/show_bug.cgi?id=359060
Camille
De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx]
De la part de LETAVERNIER Camille
Envoyé : mercredi 28 septembre 2011 10:43
À : Papyrus Project list
Objet : Re: [mdt-papyrus.dev] Papyrus refactoring
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
De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx]
De la part de LETAVERNIER Camille
Envoyé : mardi 27 septembre 2011 15:42
À : mdt-papyrus.dev@xxxxxxxxxxx
Objet : [mdt-papyrus.dev] Papyrus refactoring
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