Skip to main content
Jump to: navigation, search

Papyrus New Plugin Submission Process

Revision as of 08:58, 5 April 2011 by (Talk | contribs) (Submition Process)


All new plugins contributed to Papyrus should follow a submition process describe here. The goal of this submition process is to allows all commiters to review the new plugin before it is added to the main development trunk. The goals of this process are:

  • Allow other commiter to be informed of new plugins
  • Allow to review new plugins before they are delivered in the main trunk
  • Let other commiters have a chance to test, check and comment new plugin before it is fully part of Papyrus. This

allows to choose altogether the definitive plugin name, its target repository (core, uml, ...) and to check that coding rules are respected.

  • To provide more robust and well written plugins
  • To simplify the nightly build process
  • Allow new commiters to submit their code without being afraid of breaking Papyrus


All new plugins shoul be commited in the incoming repository.


  • Your plugin should be fully operational. Do not submit a plugin that is not running
  • Papyrus should still running without your new plugin.
  • Your plugin should follows rules describe in this document [1]
  • The name of your plugin should follow Papyrus naming rules

Submition Process

This is a draft proposal, subject to changes.

  1. Choose a name for your new project (see Papyrus_Plugin_Naming_Scheme).
  2. Develop and test your plugin on your local environement
  3. Check the "Check List" (see after)
  4. Commit your plugin in the incoming repository
  5. Send an email on the Payrus mailing list to inform other developpers
    • Mention the plugin name, its proposed future target repository
    • Give a short description of your plugin purpose
  6. Wait at least 7 days (unless you have positive feedbacks from a vast majority of commiters, and no negative one)
    • During this period, answer to remarks from others commiters, discuss, rename, do proposed enhancement...
  7. Once there are no more objections from other commiters, move your plugin to its final location
    • Use svn move to avoid lost of svn history
  8. Add a Bugzilla entry: enter a sub-task to the releng bug: 263430: [General] Add releng ( This informs the build server must be updated.

Check List

This list contains all points that should be verified before committing the plugin in the repository:

  • Plugin id should correspond to Papyrus standards. It should be meaningfull and distinguishable from other plugins (to avoid having plugins org.eclipse.papyrus.editors and org.eclipse.papyrus.editor)
    • Plugin id and project name should be exactly the same, to ease the process build
    • Plugin name should contain the '(Incubation)' label at the end
  • Plugin should be compatible with the java 1.5 library:
    • Minimal execution environment is j2se-1.5
    • JRE system library should be specified to 1.5 also
  • Plugin should contain the 'about.html' file at the root of the plugin
    • Check also that this file is included in the binary build ( -> binary build)
  • Plugin should be internationalized, with file or with the new system: PDE Tools > Internationalize
  • Plugin build should be carrefully inspected:
    • Binary build : Is everything required at runtime present? Icons folder, extension point schemas,, about.html, etc.
    • Source build should contain at least the about.hmtl file.
    • Unless exception, there should be no warnings on this file!
  • Code should contain correct headers
  • Code should be commented (javadoc)
  • Java formatter and templates shared on the SVN should be applied on the whole plugin content
  • No System.out/err.println left in the code
    • Use the papyrus log system

Back to the top