Difference between revisions of "Papyrus Developer Guide"

From Eclipsepedia

Jump to: navigation, search
(How to commit a patch)
(Add a how to section)
Line 75: Line 75:
  
 
<br>  
 
<br>  
 +
 +
== 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]]
 +
 +
 +
<br>
  
 
== Papyrus Bugzilla usage  ==
 
== Papyrus Bugzilla usage  ==
Line 84: Line 95:
 
The category helps to filter the bugs for developers. There are already some existing categories: General, XXX Diagram, Common, Property View, etc.  
 
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 ===
+
=== 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 :  
+
(For further information, see http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf)
*(1) I, Forename Name, wrote 100% of the code I've provided.
+
 
*(2) This code contains no cryptography
+
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&nbsp;:  
*(3) I have the right to contribute the code to Eclipse.
+
 
 +
*(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.
 
*(4) I contribute the content under the EPL.
  
=== How to commit a patch ===
+
=== 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.
+
Before commiting a patch, you should verify that the contributor has written the following lines in the comment&nbsp;:  
*(2) This code contains no cryptography
+
 
*(3) I have the right to contribute the code to Eclipse.
+
*(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.
 
*(4) I contribute the content under the EPL.
  
If not, he must do that before you commit its patch!
+
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 :  
+
*If the writer is an employee of the same company and if the compagny has signed a Member Commiter Agreement&nbsp;: after the commit, you should comment the attachment writing&nbsp;:  
**Here is a contribution from one employee of "the name of the company"
+
**Here is a contribution from one employee of "the name of the company"  
 
**The company has signed a Member Commiter Agreement.  
 
**The company has signed a Member Commiter Agreement.  
 
**The contribution does not need a CQ.  
 
**The contribution does not need a CQ.  
**I've committed this contribution.
+
**I've committed this contribution.  
**Committed revision xxx.
+
**Committed revision xxx.  
 
**Set the field iplog to +
 
**Set the field iplog to +
  
Note : In reality, you should have the autorization of the PMC before doing this commit.
+
Note&nbsp;: In reality, you should have the autorization of the PMC before doing this commit.  
  
*If the writer is not an employee of the CEA : you need to do a CQ (http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf)
+
*If the writer is not an employee of the CEA&nbsp;: you need to do a CQ (http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf)
  
 
*In all other cases, see http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf
 
*In all other cases, see http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf
  
== How to commit ==
+
== How to commit ==
*Before to commit, you should verify these items :  
+
 
** your code is formatted using the Papyrus Template
+
*Before to commit, you should verify these items&nbsp;:  
** each file has an header with the EPL licence and your name
+
**your code is formatted using the Papyrus Template  
** all strings are externalized
+
**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".
 
*Moreover, if you want to commit a patch, please see the point "How to commit a patch".
  
*During the commit :  
+
*During the commit&nbsp;:  
** you should comment your commit and precise the id of the bug
+
**you should comment your commit and precise the id of the bug
  
*After the commit
+
*After the commit  
**Write the following comment in the bug : Commited in Rxxx
+
**Write the following comment in the bug&nbsp;: Commited in Rxxx
  
 
== Papyrus Log  ==
 
== Papyrus Log  ==

Revision as of 06:01, 14 April 2011

Contents

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

Specifications

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