Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Papyrus New Plugin Submission Process"

(Check List)
Line 59: Line 59:
 
*No System.out/err.println left in the code
 
*No System.out/err.println left in the code
 
**Use the papyrus log system
 
**Use the papyrus log system
 +
 +
[[Category:Papyrus]]

Revision as of 11:50, 16 May 2014

Overview

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

incoming

All new plugins shoul be commited in the incoming repository.

Prerequesites

  • 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

Submission Process

This is a draft proposal, subject to changes.

  1. Add a Bugzilla entry
  2. Choose a name for your new project (see Papyrus_Plugin_Naming_Scheme).
  3. Develop and test your plugin in a branch named bugs/<bug-id>-<short-desc> (e.g. bugs/12345-myFeature)
  4. Check the "Check List" (see after)
  5. Send an email on the Payrus mailing list to inform other developpers
    • Mention the plugin name
    • 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, merge your branch to master

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 should be compatible with the java 1.6 library:
    • Minimal execution environment is JavaSE-1.6
    • JRE system library should be specified to 1.6 also
  • 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

Back to the top