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/Papyrus Developer Guide/How To- Code Contributing"

(20 intermediate revisions by 4 users not shown)
Line 1: Line 1:
 +
== Code Style ==
 +
*'''default''' keyword in Interfaces: should be avoided and only used if unavoidable and justified (to prevent unnecessary API break for example)
 +
*'''var''' keyword is forbidden
 +
*'''lambda expressions''' are allowed, but must be commented to ease the understanding
 +
 
== Code Contribution  ==
 
== Code Contribution  ==
  
Line 7: Line 12:
 
*'[' ''Category'' ']' ''NameOfTheTask''<br>
 
*'[' ''Category'' ']' ''NameOfTheTask''<br>
  
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.
 +
 
 +
As a reminder, the lifecycle of bugs is located here: [[Development Resources/HOWTO/Bugzilla Use|Bugzilla Use]]
  
 
=== How to contribute code with Gerrit (non commiter)  ===
 
=== How to contribute code with Gerrit (non commiter)  ===
Line 13: Line 20:
 
If you want to contribute code, and you are not a commiter, here is how to proceed [[Papyrus Developer Guide/How to Contribute to Papyrus with Gerrit]]
 
If you want to contribute code, and you are not a commiter, here is how to proceed [[Papyrus Developer Guide/How to Contribute to Papyrus with Gerrit]]
  
=== How to contribute a patch  ===
+
=== What to do to contribute a patch  ===
  
 
(For further information, see http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf)  
 
(For further information, see http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf)  
Line 26: Line 33:
 
+ Set the field Review to '?'.
 
+ Set the field Review to '?'.
  
=== How to commit a patch  ===
+
=== What to check before committing a patch  ===
  
 
Before commiting a patch, you should verify that the contributor has written the following lines in the comment&nbsp;:  
 
Before commiting a patch, you should verify that the contributor has written the following lines in the comment&nbsp;:  
Line 47: Line 54:
 
Note&nbsp;: 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&nbsp;: 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. see [https://wiki.eclipse.org/Papyrus/Papyrus_Developer_Guide/Contribution_Questionaire this guide] for more information.
  
 
*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 code ===
+
=== Code formatting ===
  
 
*Before to commit, you should verify these items&nbsp;:  
 
*Before to commit, you should verify these items&nbsp;:  
 
**your code is formatted using the Papyrus Template  
 
**your code is formatted using the Papyrus Template  
 
**each file has an header with the EPL licence and your name  
 
**each file has an header with the EPL licence and your name  
**all strings are externalized or tagged with //$NON-NLS-1$
+
**all strings are externalized or tagged with //$NON-NLS-1$. see [https://wiki.eclipse.org/Papyrus/Papyrus_Developer_Guide#String_Externalization.2FInternalization this page] for more information.
 +
**the version numbers are correcct. see [https://wiki.eclipse.org/Version_Numbering this guide] for more information.
  
 
*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".
  
 +
===String Externalization/Internalization===
 +
*the goal of the externalization process is to distinguish the string used as messages and visible by the final user and the string required in your code, but not visible for the user,
 +
 +
Follow this [[Papyrus_Developer_Guide/Externalize_Strings_In_Java | link]] for a guide on externalization in Eclipse.
 +
 +
=== Write Documentation for Papyrus  ===
 +
Each new contribution must contribute to the documentation (behavior changes or new feature).
 +
The documentation must be splitted in two parts:
 +
*user documentation
 +
*developer documentation
 +
 +
How to - Related to documentation [[Papyrus Developer Guide/Writing Documentation]]
 +
 +
=== Plugin Versioning - Deprecated code===
 +
Using the @Deprecated tag, you must do these things in the same time:
 +
*increase the minor version of the plugin (of course, only if it has not yet be done since the last release)
 +
**NB :  if you just add @Deprecated tag in a plugin, it is normally not required to increase the plugin version. Nevertheless, we decided to increase the minor of a such plugin, in order to be able to know easily when the object became deprecated. Depending of the API Tools configuration, you can get an error doing this. In this case configure your API tools to ignore it.
 +
* indicate in the comment the plugin version when the class/method became deprecated
 +
* open a bug to remove the deprecated class/method in the next major release
 +
* reference this bug in the comment of the deprecated class/method
 +
* (optional) indicate in the comment in which major release the class/method will be remove
 +
 +
Add the end, you must have something like that:
 +
 +
 +
<nowiki>
 +
/**
 +
*
 +
* @deprecated since 3.1
 +
*            use {@link org.eclipse.papyrus.infra.gmfdiag.common.structure.DiagramStructure} API instead
 +
*
 +
*            This class will be removed in Papyrus 5.0, see Bug 541027
 +
*
 +
*
 +
*/
 +
@Deprecated
 +
public abstract class DiagramStructure {
 +
...
 +
}
 +
</nowiki>
 +
 +
=== Commit message ===
 
*During the commit&nbsp;:  
 
*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. see [https://wiki.eclipse.org/Papyrus/Papyrus_Developer_Guide/How_to_Contribute_to_Papyrus_with_Gerrit this page] for more information about contributing through git and gerrit.
 +
 
 +
== Code Reviews ==
 +
 
 +
Unless there is a good reason as to why, it is the Reviewer that is allowed to merge/push the gerrit patch into the repository. The reviewer must never be the committer of the patch to keep a two way check and minimize errors.<br/>
 +
Here are some guidelines (which may be altered and/or improved) that every reviewer and committer should follow:
 +
* '''Headers''': The headers must include a new entry for each contribution. It will include the bug number, the committer identification (the name is not mandatory, but the company is), updated date brackets (e.g. 2015-2018), respect the format below.
 +
In addition they must respect the EPL2.0 licensing and, in case of a plugin, include the about.html with the EPL2.0 license summary.
 +
/*****************************************************************************
 +
* Copyright (c) 2015, 2018 CEA LIST, Committer Name, and others.
 +
*
 +
* All rights reserved. This program and the accompanying materials
 +
* are made available under the terms of the Eclipse Public License 2.0
 +
* which accompanies this distribution, and is available at
 +
* https://www.eclipse.org/legal/epl-2.0/
 +
*
 +
* SPDX-License-Identifier: EPL-2.0
 +
*
 +
* Contributors:
 +
* CEA LIST - Initial API and implementation
 +
* Committer Name (CEA LIST) committer.name@cea.fr - Bug 492522, Bug XXXXXX
 +
*****************************************************************************/
 +
 
 +
###############################################################################
 +
# Copyright (c) 2013, 2018 CEA LIST, Committer Name, and others.
 +
#
 +
# All rights reserved. This program and the accompanying materials
 +
# are made available under the terms of the Eclipse Public License 2.0
 +
# which accompanies this distribution, and is available at
 +
# https://www.eclipse.org/legal/epl-2.0/
 +
#
 +
# SPDX-License-Identifier: EPL-2.0
 +
#
 +
# Contributors:
 +
#
 +
###############################################################################
 +
 
 +
* '''Javadoc''': It should exist for all methods (sometimes a simple @Inherited is enough). Generated javadoc should not be sufficient unless it expresses clearly what the method do, its parameters and return values.
 +
* '''Strings''': Verify the Non-NLS markers.
 +
* '''Tags''': (@since plugin-number, ...)
 +
/**
 +
* Constructs an Editor for multiple Integer values.
 +
* The widget is a List, with controls to move values up/down, add values and remove values.
 +
*
 +
* @param parent
 +
*            The Composite in which this editor is created
 +
* @param directCreation
 +
*            Indicates if the creation and modification are directed.
 +
* @param directCreationWithTreeViewer
 +
*            Indicates if the creation and modification are directed on the TreeViewer.
 +
* @param style
 +
*            The List's style
 +
*
 +
* @since 3.1
 +
*/
 +
public MultipleIntegerEditor(Composite parent, ...){}
 +
 
 +
* '''Version numbers''': A plugin's version should reflect its changes. Above is a linked to the guidelines and you can use tools to help you such as the integrated Eclipse's API tools.
 +
* '''Reexports''': A contributed code should never introduce any 'hidden' dependencies such as reexporting plugins dependencies.
 +
* '''Visibility ordering''': There is no order of methods or variables in a class (private, public or protected). On the other hand, there is an order when dealing with keywords (private static final Type).
 +
* '''Attributes''': All attributes, field must be at beginning of the class
 +
* '''Returns and conditions''': You can have as many 'return' statement you need in a method.
 +
 
 +
* '''Features and Manifest''': The variables should be externalized in a properties files when possible. and the features should point to the eclipse license plugin instead of declaring their own.
 +
<feature
 +
      id="org.eclipse.papyrus.XXXXXXX.feature"
 +
      version="2.0.0.qualifier"
 +
      label="%featureName"
 +
      provider-name="%providerName"
 +
      license-feature="org.eclipse.license"
 +
      license-feature-version="2.0.0">
 +
 +
  <description>
 +
      %description
 +
  </description>
 +
 +
  <copyright>
 +
      %copyright
 +
  </copyright>
 +
 +
  <license url="%licenseURL">
 +
      %license
 +
  </license>
 +
===API===
 +
* Code of plugins shall be inside internal package
 +
* API shall be public and each classe presence shall be justified by implementation of usecase
 +
* The usecase are store inside the plugin  the name of the file '''name.usecases'''
 +
* The grammar is:
 +
'''Requirement :''' requirementID ''':''' text
 +
'''Code Instruction: ''' path to the API class
 +
 
 +
* See the folowing example
 +
 
 +
# Requirements defined for the validation of Papyrus profile plug-in
 +
# This file must be filled by developer when a task is done in the validation of a profile plug-in
 +
 +
# General Requirements
 +
Requirement: Req_Validate_Menu_ProfileValidation_001: The profile validation must be done with a button 'Validate Profile plug-in' on plug-in, in the papyrus developer
 +
menu
 +
Code instruction: - org.eclipse.papyrus.toolsmiths.validation.profile/src/org/eclipse/papyrus/toolsmiths/validation/profile/handlers/ValidateProfilePluginHandler.java
 +
- org.eclipse.papyrus.toolsmiths.validation.profile/src/org/eclipse/papyrus/toolsmiths/validation/profile/testers/ValidateProfilePluginTester.java
 +
- org.eclipse.papyrus.toolsmiths.validation.profile/plugin.xml
 +
 
 +
Requirement: Req_Validation_Dialog_ProfileValidation_002: During the validation, a progress monitor must be opened with correct explanations
 +
Code instruction: - org.eclipse.papyrus.toolsmiths.validation.profile/src/org/eclipse/papyrus/toolsmiths/validation/profile/handlers/ValidateProfilePluginHandler.java
 +
 
 +
# General Technical Requirements
 +
Requirement: ReqTechnical_Extensions_Checker_ProfileValidation_001: A checker for the extensions must be implemented
 +
Code instruction: -
 +
org.eclipse.papyrus.toolsmiths.validation.profile/src/org/eclipse/papyrus/toolsmiths/validation/profile/internal/checkers/ProfileExtensionsChecker.java
 +
 
 +
Requirement: ReqTechnical_Definition_Profile_Checker_ProfileValidation_002: A checker for the definition profile must be implemented
 +
Code instruction: -
 +
org.eclipse.papyrus.toolsmiths.validation.profile/src/org/eclipse/papyrus/toolsmiths/validation/profile/internal/checkers/ProfileDefinitionChecker.java
 +
 
 +
 
 +
 
 +
=TO BE CLEANED =
 +
== Plug-ins ==
 +
*All plug-ins must compile and run against JavaSE-1.8. Papyrus 5.0 must compile against openjdk-11.
 +
*Plug-in provider&nbsp;: ''Eclipse Modeling Project''
 +
*Version&nbsp;:
 +
***Papyrus adheres to the [[Version Numbering|Eclipse Versioning Guidelines]] for API evolution and other kinds of changes''
 +
*Plug-in name&nbsp;: must end with (Incubation) if version is less than 1.0. e.g. ''Papyrus CDO Model Repository (Incubation)''. If the version is at least 1.0.0, the (Incubation) suffix must be removed (e.g. ''Papyrus Backbone'').
 +
*Plug-in ID&nbsp;: must start with org.eclipse.papyrus
 +
*Plug-in dependencies must not be re-exported.
 +
*plug-in dependencies must be defined with min and max version values, e.g. depends on ''oep.infra.core;bundle-version="[1.2.0,2.0.0)"'' instead of ''oep.infra.core'' or ''oep.infra.core;bundle-version="1.2.0"'')
 +
**The Papyrus Developer Tools include an action '''Update Dependency Ranges''' in the '''Plug-in Tools''' context menu of plug-in projects and manifest files that automatically assigns bundle dependency ranges compatible with the current PDE target and workspace
 +
*The build.properties file describes the files that '''must''' be included at runtime. It is important to fill it properly, so that plug-ins can work correctly once installed. Especially, you should probably always include the following files and folders (When they exist), in the "Binary build" (field bin.includes in build.properties) category:
 +
**META-INF/
 +
**about.html
 +
**icons/, images/, resources/, models/, etc. (All folders containing runtime resources)
 +
**plugin.properties
 +
**plugin.xml
 +
**schema/
 +
*Do '''not''' include the following files:
 +
**.classpath
 +
**.project
 +
**bin/, src/, src-gen/, custom-src/
 +
**build.properties
 +
*The ''Source build'' (field src.includes in build.properties) category '''must''' contain the '''about.html''' file:
 +
**Optionnally, it may contain the following files:
 +
***.classpath
 +
***build.properties
 +
*It '''must not''' contain the following:
 +
**src/, src-gen/, custom-src/
 +
**All files and directories which are already contained in the "Binary build" category (Except about.html which must be contained in both Binary and Source builds)
  
*After the commit
+
plugin.xml:<br>
**Write the following comment in the bug&nbsp;: Commited in Rxxx
+
[[Image:Papyrus.codestandards.plugin.xml.png]]

Revision as of 11:07, 1 July 2020

Code Style

  • default keyword in Interfaces: should be avoided and only used if unavoidable and justified (to prevent unnecessary API break for example)
  • var keyword is forbidden
  • lambda expressions are allowed, but must be commented to ease the understanding

Code Contribution

How to add a Task (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.

As a reminder, the lifecycle of bugs is located here: Bugzilla Use

How to contribute code with Gerrit (non commiter)

If you want to contribute code, and you are not a commiter, here is how to proceed Papyrus Developer Guide/How to Contribute to Papyrus with Gerrit

What to do to contribute 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.

+ Set the field Review to '?'.

What to check before committing 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.

Code formatting

  • 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 or tagged with //$NON-NLS-1$. see this page for more information.
    • the version numbers are correcct. see this guide for more information.
  • Moreover, if you want to commit a patch, please see the point "How to commit a patch".

String Externalization/Internalization

  • the goal of the externalization process is to distinguish the string used as messages and visible by the final user and the string required in your code, but not visible for the user,

Follow this link for a guide on externalization in Eclipse.

Write Documentation for Papyrus

Each new contribution must contribute to the documentation (behavior changes or new feature). The documentation must be splitted in two parts:

  • user documentation
  • developer documentation

How to - Related to documentation Papyrus Developer Guide/Writing Documentation

Plugin Versioning - Deprecated code

Using the @Deprecated tag, you must do these things in the same time:

  • increase the minor version of the plugin (of course, only if it has not yet be done since the last release)
    • NB : if you just add @Deprecated tag in a plugin, it is normally not required to increase the plugin version. Nevertheless, we decided to increase the minor of a such plugin, in order to be able to know easily when the object became deprecated. Depending of the API Tools configuration, you can get an error doing this. In this case configure your API tools to ignore it.
  • indicate in the comment the plugin version when the class/method became deprecated
  • open a bug to remove the deprecated class/method in the next major release
  • reference this bug in the comment of the deprecated class/method
  • (optional) indicate in the comment in which major release the class/method will be remove

Add the end, you must have something like that:


/**
 *
 * @deprecated since 3.1
 *             use {@link org.eclipse.papyrus.infra.gmfdiag.common.structure.DiagramStructure} API instead
 *
 *             This class will be removed in Papyrus 5.0, see Bug 541027
 *
 *
 */
@Deprecated
public abstract class DiagramStructure {
...
}

Commit message

  • During the commit :
    • you should comment your commit and precise the id of the bug. see this page for more information about contributing through git and gerrit.

Code Reviews

Unless there is a good reason as to why, it is the Reviewer that is allowed to merge/push the gerrit patch into the repository. The reviewer must never be the committer of the patch to keep a two way check and minimize errors.
Here are some guidelines (which may be altered and/or improved) that every reviewer and committer should follow:

  • Headers: The headers must include a new entry for each contribution. It will include the bug number, the committer identification (the name is not mandatory, but the company is), updated date brackets (e.g. 2015-2018), respect the format below.

In addition they must respect the EPL2.0 licensing and, in case of a plugin, include the about.html with the EPL2.0 license summary.

/*****************************************************************************
* Copyright (c) 2015, 2018 CEA LIST, Committer Name, and others.
*
* All rights reserved. This program and the accompanying materials
* are made available under the terms of the Eclipse Public License 2.0
* which accompanies this distribution, and is available at
* https://www.eclipse.org/legal/epl-2.0/
*
* SPDX-License-Identifier: EPL-2.0
*
* Contributors:
* CEA LIST - Initial API and implementation
* Committer Name (CEA LIST) committer.name@cea.fr - Bug 492522, Bug XXXXXX
*****************************************************************************/
###############################################################################
# Copyright (c) 2013, 2018 CEA LIST, Committer Name, and others.
#
# All rights reserved. This program and the accompanying materials
# are made available under the terms of the Eclipse Public License 2.0
# which accompanies this distribution, and is available at
# https://www.eclipse.org/legal/epl-2.0/
#
# SPDX-License-Identifier: EPL-2.0
#
# Contributors:
#
###############################################################################
  • Javadoc: It should exist for all methods (sometimes a simple @Inherited is enough). Generated javadoc should not be sufficient unless it expresses clearly what the method do, its parameters and return values.
  • Strings: Verify the Non-NLS markers.
  • Tags: (@since plugin-number, ...)
/**
* Constructs an Editor for multiple Integer values.
* The widget is a List, with controls to move values up/down, add values and remove values.
*
* @param parent
*            The Composite in which this editor is created
* @param directCreation
*            Indicates if the creation and modification are directed.
* @param directCreationWithTreeViewer
*            Indicates if the creation and modification are directed on the TreeViewer.
* @param style
*            The List's style
*
* @since 3.1
*/
public MultipleIntegerEditor(Composite parent, ...){}
  • Version numbers: A plugin's version should reflect its changes. Above is a linked to the guidelines and you can use tools to help you such as the integrated Eclipse's API tools.
  • Reexports: A contributed code should never introduce any 'hidden' dependencies such as reexporting plugins dependencies.
  • Visibility ordering: There is no order of methods or variables in a class (private, public or protected). On the other hand, there is an order when dealing with keywords (private static final Type).
  • Attributes: All attributes, field must be at beginning of the class
  • Returns and conditions: You can have as many 'return' statement you need in a method.
  • Features and Manifest: The variables should be externalized in a properties files when possible. and the features should point to the eclipse license plugin instead of declaring their own.
<feature 
     id="org.eclipse.papyrus.XXXXXXX.feature" 
     version="2.0.0.qualifier"
     label="%featureName" 
     provider-name="%providerName" 
     license-feature="org.eclipse.license"
     license-feature-version="2.0.0">

  <description>
     %description
  </description>

  <copyright>
     %copyright
  </copyright>

  <license url="%licenseURL">
     %license
  </license>

API

  • Code of plugins shall be inside internal package
  • API shall be public and each classe presence shall be justified by implementation of usecase
  • The usecase are store inside the plugin the name of the file name.usecases
  • The grammar is:
Requirement : requirementID : text 
Code Instruction:  path to the API class
  • See the folowing example
# Requirements defined for the validation of Papyrus profile plug-in
# This file must be filled by developer when a task is done in the validation of a profile plug-in

# General Requirements
Requirement: Req_Validate_Menu_ProfileValidation_001: The profile validation must be done with a button 'Validate Profile plug-in' on plug-in, in the papyrus developer 
menu
Code instruction: - org.eclipse.papyrus.toolsmiths.validation.profile/src/org/eclipse/papyrus/toolsmiths/validation/profile/handlers/ValidateProfilePluginHandler.java
- org.eclipse.papyrus.toolsmiths.validation.profile/src/org/eclipse/papyrus/toolsmiths/validation/profile/testers/ValidateProfilePluginTester.java
- org.eclipse.papyrus.toolsmiths.validation.profile/plugin.xml
Requirement: Req_Validation_Dialog_ProfileValidation_002: During the validation, a progress monitor must be opened with correct explanations
Code instruction: - org.eclipse.papyrus.toolsmiths.validation.profile/src/org/eclipse/papyrus/toolsmiths/validation/profile/handlers/ValidateProfilePluginHandler.java
# General Technical Requirements
Requirement: ReqTechnical_Extensions_Checker_ProfileValidation_001: A checker for the extensions must be implemented
Code instruction: - 
org.eclipse.papyrus.toolsmiths.validation.profile/src/org/eclipse/papyrus/toolsmiths/validation/profile/internal/checkers/ProfileExtensionsChecker.java
Requirement: ReqTechnical_Definition_Profile_Checker_ProfileValidation_002: A checker for the definition profile must be implemented
Code instruction: - 
org.eclipse.papyrus.toolsmiths.validation.profile/src/org/eclipse/papyrus/toolsmiths/validation/profile/internal/checkers/ProfileDefinitionChecker.java


TO BE CLEANED

Plug-ins

  • All plug-ins must compile and run against JavaSE-1.8. Papyrus 5.0 must compile against openjdk-11.
  • Plug-in provider : Eclipse Modeling Project
  • Version :
  • Plug-in name : must end with (Incubation) if version is less than 1.0. e.g. Papyrus CDO Model Repository (Incubation). If the version is at least 1.0.0, the (Incubation) suffix must be removed (e.g. Papyrus Backbone).
  • Plug-in ID : must start with org.eclipse.papyrus
  • Plug-in dependencies must not be re-exported.
  • plug-in dependencies must be defined with min and max version values, e.g. depends on oep.infra.core;bundle-version="[1.2.0,2.0.0)" instead of oep.infra.core or oep.infra.core;bundle-version="1.2.0")
    • The Papyrus Developer Tools include an action Update Dependency Ranges in the Plug-in Tools context menu of plug-in projects and manifest files that automatically assigns bundle dependency ranges compatible with the current PDE target and workspace
  • The build.properties file describes the files that must be included at runtime. It is important to fill it properly, so that plug-ins can work correctly once installed. Especially, you should probably always include the following files and folders (When they exist), in the "Binary build" (field bin.includes in build.properties) category:
    • META-INF/
    • about.html
    • icons/, images/, resources/, models/, etc. (All folders containing runtime resources)
    • plugin.properties
    • plugin.xml
    • schema/
  • Do not include the following files:
    • .classpath
    • .project
    • bin/, src/, src-gen/, custom-src/
    • build.properties
  • The Source build (field src.includes in build.properties) category must contain the about.html file:
    • Optionnally, it may contain the following files:
      • .classpath
      • build.properties
  • It must not contain the following:
    • src/, src-gen/, custom-src/
    • All files and directories which are already contained in the "Binary build" category (Except about.html which must be contained in both Binary and Source builds)

plugin.xml:
Papyrus.codestandards.plugin.xml.png

Back to the top