Papyrus New Plugin Submission 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
- 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 
- The name of your plugin should follow Papyrus naming rules
This is a draft proposal, subject to changes.
- Add a Bugzilla entry
- Choose a name for your new project (see Papyrus_Plugin_Naming_Scheme).
- Develop and test your plugin in a branch named bugs/<bug-id>-<short-desc> (e.g. bugs/12345-myFeature)
- Check the "Check List" (see after)
- Send an email on the Payrus mailing list to inform other developpers
- Mention the plugin name
- Give a short description of your plugin purpose
- 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...
- Once there are no more objections from other commiters, merge your branch to master
- enter a sub-task to the releng bug: 263430: [General] Add releng (https://bugs.eclipse.org/bugs/show_bug.cgi?id=263430). This informs the build server must be updated.
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 should be compatible with the java 1.7 (Mars) or 1.8 (Neon) library:
- Minimal execution environment is JavaSE-1.7 (Or JavaSE-1.8 / )
- JRE system library should be specified to 1.7 also (Or JavaSE-1.8)
- Plugin should contain the 'about.html' file at the root of the plugin
- Check also that this file is included in the source and binary builds (build.properties -> binary build, source build)
- Plugin should be internationalized, with plugin.properties 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, plugin.properties, 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 repository should be applied on the whole plugin content
- No System.out/err.println left in the code
- Use the papyrus log system