Jump to: navigation, search

Papyrus/Papyrus Developer Guide

< Papyrus
Revision as of 06:01, 14 April 2011 by Cedric.dumoulin.lifl.fr (Talk | contribs) (Add a how to section)

Development Environment

To ease the development on Papyrus, each member of the team works with basically the same configuration.

Common Environment

Following is a description of the basic configuration:

  • The latest Eclipse Modeling release.
  • [1] SVN Subversive (or Subclipse)
  • [2] CheckStyle
  • [3] JAutoDoc

Required External Plugins

Papyrus requires some external plugins in order to compile.
The following page maintain a list of Papyrus Required External Plugins

Development Plan


The specifications are available here : http://wiki.eclipse.org/Papyrus_Developer_Guide/Specifications

Getting the code

Connecting to the svn

The code is available under svn at this location http://dev.eclipse.org/svnroot/modeling/org.eclipse.mdt.papyrus/

Retrieve code

PSF Following files will allow you to import all Papyrus plugins used during build phase:

Retrieve configuration files

The Papyrus Code Templates and Java Formatter files are available under the Papyrus repository in the plugin org.eclipse.papyrus.doc under the folder "templates"
FAQ How do I control the Java formatter
FAQ How can templates make me the fastest coder ever
Checkstyle : available soon

The note explains how to install the templates in your environment.

Papyrus Generation

Papyrus Code Standards

  • Java Doc - every class, method and field including private ones should be documented with Java Doc
  • No abbreviations - the class, methods and variables should have meaningful names
  • Formatting - the code should be formatted in accordance with format templates
  • Compile - the modified code and other plugins should be compilable. Be sure to use Java 1.5 code compatibility. Check other plugins that could be influenced before commiting!
  • Standard Java Rules coding - Unless specified differently, the Java Standard Coding rules should be applied : no abbreviations, variables starting with lower case; class and types with upper case; Composed name separated with upper case; no underscore in names; ...
  • In case of doubt - check existing code from those following the rules :-)

Papyrus Coding guidelines

A few points may be a little tricky when coding for Papyrus. Among them :

Papyrus Plugin Naming Scheme and Folders Structure

Papyrus Command Execution, History, Undo/Redo

How To ...

Commit, Report Bugs, patchs

How To - related to reporting bugs, patching, commit, ...

Papyrus Code Examples

How to - Related to Papyrus code,Papyrus Developer Guide/How To Code Examples

Papyrus Bugzilla usage

When adding a task to the buzilla, the following grammar should be used:

  • '[' Category ']' NameOfTheTask

The category helps to filter the bugs for developers. There are already some existing categories: General, XXX Diagram, Common, Property View, etc.

How to provide a patch

(For further information, see http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf)

When a non-committer wants to contribute to Papyrus, he must create patchs and attach them to a bug. In the comment of each patch, he must write :

  • (1) I, Forename Name, wrote 100% of the code I've provided.
  • (2) This code contains no cryptography
  • (3) I have the right to contribute the code to Eclipse.
  • (4) I contribute the content under the EPL.

How to commit a patch

Before commiting a patch, you should verify that the contributor has written the following lines in the comment :

  • (1) I, Forename Name, wrote 100% of the code I've provided.
  • (2) This code contains no cryptography
  • (3) I have the right to contribute the code to Eclipse.
  • (4) I contribute the content under the EPL.

If not, he must do that before you commit its patch!

  • If the writer is an employee of the same company and if the compagny has signed a Member Commiter Agreement : after the commit, you should comment the attachment writing :
    • Here is a contribution from one employee of "the name of the company"
    • The company has signed a Member Commiter Agreement.
    • The contribution does not need a CQ.
    • I've committed this contribution.
    • Committed revision xxx.
    • Set the field iplog to +

Note : In reality, you should have the autorization of the PMC before doing this commit.

How to commit

  • Before to commit, you should verify these items :
    • your code is formatted using the Papyrus Template
    • each file has an header with the EPL licence and your name
    • all strings are externalized
  • Moreover, if you want to commit a patch, please see the point "How to commit a patch".
  • During the commit :
    • you should comment your commit and precise the id of the bug
  • After the commit
    • Write the following comment in the bug : Commited in Rxxx

Papyrus Log

Papyrus Build Process

Papyrus Creation Type

New plugin Submition Process

New plugin should follow the submition process describe here: Papyrus New Plugin Submition Process