https://wiki.eclipse.org/api.php?action=feedcontributions&user=Patrick.Tessier.cea.fr&feedformat=atomEclipsepedia - User contributions [en]2024-03-29T09:55:26ZUser contributionsMediaWiki 1.26.4https://wiki.eclipse.org/index.php?title=Papyrus/Papyrus_Developer_Guide/How_To-_Code_Contributing&diff=447313Papyrus/Papyrus Developer Guide/How To- Code Contributing2023-05-09T12:26:04Z<p>Patrick.Tessier.cea.fr: /* Code Rules */</p>
<hr />
<div>__TOC__<br />
<br />
<br />
All papyrus contributors shall follow these rules:<br />
<br />
== Write a Bugzilla task ==<br />
When adding a task to the buzilla, the following grammar should be used: <br />
<br />
*'[' ''Category'' ']' ''NameOfTheTask''<br><br />
<br />
The category helps to filter the bugs for developers. There are already some existing categories: General, XXX Diagram, Common, Property View, etc.<br />
<br />
As a reminder, the lifecycle of bugs is located here: [[Development Resources/HOWTO/Bugzilla Use|Bugzilla Use]]<br />
<br />
*Your contribution shall be associated to a bug refenced in the bugzilla.<br />
*When a bug is opened/resolved/closed the Target Milestone must be filled. For example the bug has been fixed for the service release 3 of oxygen, the target milestone is 3.3.<br />
<br />
<br />
== Write the code ==<br />
<br />
=== Papyrus Plugin Structure ===<br />
<br />
*Papyrus plugin naming scheme and folder structure used to locate and name plugins is described here: [[Papyrus/Papyrus_Developer_Guide/Papyrus_Plugin_Naming_Scheme]]<br />
<br />
*All plug-ins must compile and run against JavaSE-1.8. Papyrus 5.0 must compile against openjdk-11.<br />
*Plug-in provider&nbsp;: ''Eclipse Modeling Project'' <br />
*Version&nbsp;: <br />
***Papyrus adheres to the [[Version Numbering|Eclipse Versioning Guidelines]] for API evolution and other kinds of changes''<br />
*Plug-in name&nbsp;: must end with (Incubation) if version is less than 1.0.0 . If the version is at least 1.0.0, the (Incubation) suffix must be removed.<br />
*Plug-in ID&nbsp;: must start with org.eclipse.papyrus.<br />
*Plug-in dependencies must not be re-exported.<br />
*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"'')<br />
**The Papyrus Developer Tools has 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<br />
*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: <br />
**META-INF/ <br />
**about.html <br />
**icons/, images/, resources/, models/, etc. (All folders containing runtime resources) <br />
**plugin.properties <br />
**plugin.xml <br />
**schema/ <br />
*Do '''not''' include the following files: <br />
**.classpath <br />
**.project <br />
**bin/, src/, src-gen/, custom-src/ <br />
**build.properties <br />
*The ''Source build'' (field src.includes in build.properties) category '''must''' contain the '''about.html''' file: <br />
*It '''must not''' contain the following: <br />
**src/, src-gen/, custom-src/ <br />
**All files and directories are already contained in the "Binary build" category (Except the about.html which must be contained in both Binary and Source builds)<br />
<br />
plugin.xml:<br><br />
[[Image:Papyrus.codestandards.plugin.xml.png]]<br />
<br />
=== Papyrus Feature Structure ===<br />
<br />
* Papyrus feature id scheme: org.eclipse.papyrus.&lt;feature.name&gt;.feature <br />
**e.g. ''org.eclipse.papyrus.infra.core.feature'' <br />
* Papyrus feature Label scheme: Papyrus &lt;Feature Name&gt;<br />
**e.g. ''Papyrus core'' <br />
If your feature is still in the incubation state you should add the following to your label: (Incubation)<br />
*Each feature must contain the Eclipse licence reference:<br />
<feature<br />
id="org.eclipse.papyrus.editor.feature"<br />
version="2.0.0.qualifier"<br />
label="%featureName"<br />
provider-name="%providerName" <br />
license-feature="org.eclipse.license"<br />
license-feature-version="2.0.2"><br />
<br />
<description url="https://eclipse.org/papyrus/"><br />
%description<br />
</description><br />
<br />
<copyright><br />
%copyright<br />
</copyright><br />
<br />
<license url="%licenseURL"><br />
%license<br />
</license> <br />
...<br />
</feature><br />
<br />
*The build.properties file must contain the following files in the "Binary build" section: <br />
**feature.properties which must contains:<br />
*** featureName<br />
*** providerName<br />
*** description<br />
*** copyright<br />
**feature.xml<br />
<br />
*The feature must only includes the repository's Papyrus plugins. If you need to make it depends on external plugins or features, be they from another Papyrus repository or any other repository, they should be added through the require of import mechanism. Refrain from using the include method as much as possible.<br />
<br />
=== Code Formatting ===<br />
Before writing any code you should check that you have the papyrus templates set as your format in your IDE.<br />
These can be [https://wiki.eclipse.org/Papyrus/Papyrus_Developer_Guide#Apply_Papyrus_Configuration_Files retrieved following these steps].<br />
<br />
These could also be retreived and applied from the .settings folder of each plugins. (An example can be found [https://git.eclipse.org/c/papyrus/org.eclipse.papyrus.git/tree/plugins/infra/core/org.eclipse.papyrus.infra.core.log/.settings here])<br />
<br />
=== Code Rules ===<br />
Before committing, you should verify these items&nbsp;: <br />
*'''copyright''' each file has an header with the EPL licence and your name <br />
* '''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.<br />
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.<br />
/*****************************************************************************<br />
* Copyright (c) 2015, 2018 CEA LIST, Committer Name, and others.<br />
*<br />
* This program and the accompanying materials<br />
* are made available under the terms of the Eclipse Public License 2.0<br />
* which accompanies this distribution, and is available at<br />
* https://www.eclipse.org/legal/epl-2.0/<br />
*<br />
* SPDX-License-Identifier: EPL-2.0<br />
*<br />
* Contributors:<br />
* CEA LIST - Initial API and implementation<br />
* Committer Name (CEA LIST) committer.name@cea.fr - Bug 492522, Bug XXXXXX<br />
*****************************************************************************/<br />
<br />
###############################################################################<br />
# Copyright (c) 2013, 2018 CEA LIST, Committer Name, and others.<br />
#<br />
# This program and the accompanying materials<br />
# are made available under the terms of the Eclipse Public License 2.0<br />
# which accompanies this distribution, and is available at<br />
# https://www.eclipse.org/legal/epl-2.0/<br />
#<br />
# SPDX-License-Identifier: EPL-2.0<br />
#<br />
# Contributors:<br />
#<br />
###############################################################################<br />
<br />
*'''default''' keyword in Interfaces: should be avoided and only used if unavoidable and justified (to prevent unnecessary API break for example)<br />
*'''var''' keyword is forbidden<br />
*'''lambda expressions''' are allowed, but must be commented to ease the understanding<br />
*'''externalized''' strings or tagged with //$NON-NLS-1$. 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 [https://wiki.eclipse.org/Papyrus/Papyrus_Developer_Guide/Externalize_Strings_In_Java link] for a guide on externalization in Eclipse.<br />
* '''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).<br />
* '''Naming''': No abbreviations - the class, methods and variables should have meaningful names.<br />
* '''Attributes''': All attributes, field must be at beginning of the class<br />
* '''Returns and conditions''': You can have as many 'return' statement you need in a method.<br />
* '''Javadoc''': It should exist for all methods (sometimes a simple @Inherited is enough). Automatic generation of JavaDoc comments may help, but the automatically generated comments are '''templates'''. They are not sufficient. It is better not to generate javadoc comments than to generate empty comments. <br />
* '''@SuppressWarnings''' annotations : these annotations are allowed but are not mandatory.<br />
* '''Tags''': (@since plugin-number, ...)<br />
/**<br />
* Constructs an Editor for multiple Integer values.<br />
* The widget is a List, with controls to move values up/down, add values and remove values.<br />
*<br />
* @param parent<br />
* The Composite in which this editor is created<br />
* @param directCreation<br />
* Indicates if the creation and modification are directed.<br />
* @param directCreationWithTreeViewer<br />
* Indicates if the creation and modification are directed on the TreeViewer.<br />
* @param style<br />
* The List's style<br />
*<br />
* @since 3.1<br />
*/<br />
public MultipleIntegerEditor(Composite parent, ...){}<br />
* '''Reexports''': A contributed code should never introduce any 'hidden' dependencies such as reexporting plugins dependencies.<br />
* '''Contribution''': A newly written code or plugin should always be added to the relevant poms and features.<br />
*'''versions numbers''' are correct. see [https://wiki.eclipse.org/Version_Numbering this guide] for more information.<br />
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/><br />
* all generated code shall be contained in the directory '''src-gen'''. Note that all code in this directory is not participant to the API.<br />
<br />
Here are some guidelines (which may be altered and/or improved) that every reviewer and committer should follow:<br />
<br />
====Generated Code====<br />
'''EMF''', '''GMF''' and '''Xtend''' are used to generate java code.<br />
*'''EMF''' and '''GMF'''<br />
** when we use these frameworks, the generation must be done in a dedicated folder, generally named '''src-gen'''.<br />
** this '''src-gen''' must only contains the generated code<br />
** this generated code must not be modified by the developper, several ways are available to avoid to have to write ''@Generated NOT'' in the generated code.<br />
** if for a well identified usecase you need to modify the generated code, after a validation of the Papyrus Team, you must write a dedicated JUnit tests to check that your custom code is never erased by a future re-generation.<br />
** currently this generated code is committed on the git, but maybe in the future it will be generated by the build process.<br />
** concerning the modifications done in an *.ecore or *.gmfgen file, we recommand to update the year in the generated header in the *.ecore/*.gmfgen file and that's all. For example, just edit the line '''Copyright (c) 2014 CEA LIST and others.''' becomes '''Copyright (c) 2014, 2021 CEA LIST and others.''' Of course, you can also add your company into this line. <br />
<br />
*'''Xtend'''<br />
** when we use these frameworks, the generation must be done in a dedicated folder generally, named '''xtend-gen'''.<br />
** as for '''EMF''', you must not modify the generated code.<br />
** the code is generated by the build process, so the generated java code must not be committed on the git.<br />
<br />
===Logger===<br />
You must '''not''' use the standard console output in Papyrus plug-ins. Use the [https://wiki.eclipse.org/Papyrus/Papyrus_Developer_Guide/Papyrus_Log Papyrus log] instead.<br />
<br />
=== Plugin Versioning - Deprecated code ===<br />
Using the @Deprecated tag, you must do these things in the same time:<br />
*increase the minor version of the plugin (of course, only if it has not yet be done since the last release)<br />
**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.<br />
* indicate in the comment the plugin version when the class/method became deprecated<br />
* open a bug to remove the deprecated class/method in the next major release<br />
* reference this bug in the comment of the deprecated class/method<br />
* (optional) indicate in the comment in which major release the class/method will be remove<br />
<br />
Add the end, you must have something like that: <br />
<br />
<nowiki><br />
/**<br />
* @deprecated since 3.1<br />
* use {@link org.eclipse.papyrus.infra.gmfdiag.common.structure.DiagramStructure} API instead<br />
*<br />
* This class will be removed in Papyrus 5.0, see Bug 541027<br />
*/<br />
@Deprecated<br />
public abstract class DiagramStructure {<br />
...<br />
}<br />
</nowiki><br />
<br />
=== Automatic check ===<br />
<br />
Most of these rules are checked automatically when running the Papyrus tests. If you want to check them locally, use the plug-in ''org.eclipse.papyrus.bundles.tests'' (''Run as &gt; Junit plug-in test'' or use the ''*.launch'' file from this plug-in). This plug-in can be retrieved on the Papyrus Git repository: [https://git.eclipse.org/c/papyrus/org.eclipse.papyrus.git/tree/tests/junit/framework/org.eclipse.papyrus.bundles.tests org.eclipse.papyrus.bundles.tests].<br />
<br />
=== API ===<br />
* Code of plugins shall be inside internal package<br />
* API shall be public and each classe presence shall be justified by implementation of usecase<br />
* The usecase are store inside the plugin the name of the file '''XXX.usecases.md'''<br />
* The grammar is:<br />
### requirement text <br />
* qualified name of the class<br />
<br />
* See the following example<br />
<br />
### The profile validation must be done with a button 'Validate Profile plug-in' on plug-in, in the papyrus developer menu<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.handlers.ValidateProfilePluginHandler<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.testers.ValidateProfilePluginTester<br />
* plugin.xml<br />
### During the validation, a progress monitor must be opened with correct explanations<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.handlers.ValidateProfilePluginHandler<br />
### A checker for the extensions must be implemented<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.internal.checkers.ProfileExtensionsChecker<br />
### A checker for the definition profile must be implemented<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.internal.checkers.ProfileDefinitionChecker<br />
<br />
== Write Documentation for Papyrus ==<br />
Each new contribution must contribute to the documentation (behavior changes or new feature). <br />
The documentation must be splitted in two parts: <br />
*user documentation<br />
*developer documentation<br />
<br />
How to - Related to documentation [[Papyrus Developer Guide/Writing Documentation]]<br />
<br />
== Contribute ==<br />
<br />
===ECA===<br />
The developer should have signed the [https://www.eclipse.org/legal/ECA.php Eclipse Contributor Agreement]<br />
If the writer is an employee and his company has signed a Member Committer Agreement&nbsp;: after the commit, you should comment the attachment writing&nbsp;: <br />
*Here is a contribution from one employee of "the name of the company" <br />
*The company has signed a Member Committer Agreement. <br />
*The contribution does not need a CQ. <br />
*I've committed this contribution. <br />
*Committed revision xxx. <br />
*Set the field iplog to +<br />
<br />
Note&nbsp;: In reality, you should have the authorization of the PMC before doing this commit.<br />
<br />
=== CQs ===<br />
Remember to check on the current CQs to see if they are still current and that we will not miss any currently required dependencies (e.g. glazed lists in the new orbit or the new apache.common.io dependency) as well as the IPlogs. A quick tutorial on CQs can be found [https://wiki.eclipse.org/Papyrus_Developer_Guide/Contribution_Questionaire here].<br />
<br />
If you have any doubt about your contribution you can always check this [https://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf Eclipse chart] for more information.<br />
<br />
=== Gerrit ===<br />
<br />
If you want to contribute code, and you are not a committer, here is how to proceed:<br />
<br />
When a non-committer wants to contribute to Papyrus, he must create patchs and attach them to a bug using the Bug number in the message (e.g. commit -m "Bug 561154 - xyz"), this will automatically contribute the patch to the Bugzilla ticket. In the comment of each patch, he must write&nbsp;: <br />
<br />
* I, Forename Name, wrote 100% of the code I've provided. <br />
* This code contains no cryptography <br />
* I have the right to contribute the code to Eclipse. <br />
* I contribute the content under the EPL 2.0.<br />
<br />
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.<br />
<br />
Please, note that contributions with Merge commits will be rejected. We prefer rebased contributions to get a linear history.<br />
<br />
== Code Reviews ==<br />
The reviewer shall verify that the contribution respects all [https://wiki.eclipse.org/Papyrus/Papyrus_Developer_Guide/How_To-_Code_Contributing#Code_Rules aforementioned rules].<br />
<br />
Therefore, If there are unmerged, and chained, contributions on gerrit, any correction based on comments should be contributed as an amend of the existing patch and the next, chained, contributions rebased on top of it (and not in a future contribution).<br />
<br />
== Merge ==<br />
Eclipse release calendar is detailled [[Simultaneous_Release|here]]. Each date of releases (M1, M2, M3, RC1, RC2 and GA) for the new Eclipse version is defined in a associated wiki page of the Eclipse version). <br />
<br />
Contributions should be merged before:<br />
*M2+<br />
It is forbidden to modify the GUI. Only important bug fixes should be merged. <br />
Creation of a branch (tag) for the release<br />
*M3+<br />
It is forbidden to modify the features and general architecture.<br />
*RC1+<br />
Its forbidden to merge contribution. Only by the project Chief for critical bugs.<br />
<br />
[[Category:Papyrus]]</div>Patrick.Tessier.cea.frhttps://wiki.eclipse.org/index.php?title=Papyrus_Developer_Guide/Release_Process:_How_To/Prepare_the_GA_Release&diff=446245Papyrus Developer Guide/Release Process: How To/Prepare the GA Release2022-11-24T13:30:30Z<p>Patrick.Tessier.cea.fr: /* Review process */</p>
<hr />
<div>==Check list to publish a release for papyrus project leader==<br />
<br />
This step is among the most important ones to take so do not be shy and you should annoy your project lead as much as necessary until this is handled !<br />
<br />
=== Eclipse project page ===<br />
Do not forget to amend/complete the page dedicated to the release [https://projects.eclipse.org/projects/modeling.mdt.papyrus here]. Verify that all the associated bugs are listed and the new and noteworthy that were integrated are mentioned and references=d.<br />
If some bugs were not treated in this release migrate the milestone to the next release.<br />
* update information for the version to release https://projects.eclipse.org/projects/modeling.mdt.papyrus<br />
<br />
===IP Log managment===<br />
* Verifiy and generate the IP log and post an IP log review on the same page<br />
* If needed, create CQ. Usualy, all CQs should have be done before the review process. You can view the process [https://wiki.eclipse.org/Papyrus/Papyrus_Developer_Guide/Contribution_Questionaire here].<br />
* Then submit the review<br />
* A bug is generated that you '''must''' follow for example https://dev.eclipse.org/ipzilla/show_bug.cgi?id=16458 (NB: only the committers have access to the ipzilla)<br />
<br />
===Review process===<br />
* Could be done as the same time as IP log<br />
** Go to the page https://projects.eclipse.org/projects/modeling.mdt.papyrus<br />
** Launch the review for the release. when there is review, an eye icon is displayed on the line <br />
* An issue is generated that you '''must''' follow for example : https://gitlab.eclipse.org/eclipsefdn/emo-team/emo/-/issues/406<br />
*After the IP log<br />
** You will need to ask for a release approbation by you modeling PMC and contribute it to the 'release Bug' as illustrated by: https://www.eclipse.org/lists/modeling-pmc/msg04604.html. This can be obtained by searching for ''Archives modeling-pmc'' in most search engines.<br />
<br />
== Official release (post RC2) ==<br />
<br />
After you have released all the candidates, there usually is a quiet week when all the projects are to check for breaking or critical bugs. This time can be used, at the earliest, to initiate the final stage of the release plan.<br />
<br />
==== Update the RCP and the SDK versions ====<br />
Do not forget that you will need to release the RCP corresponding to the release. therefore you should build a new one just after the final RC build and keep the artifacts to publish them the day you do the official release.<br/><br />
Do not forget to create a patch incrementing the SDK features and the RCP product in order to begin anew as soon as possible. (i.e. the day after you push the final RC artifacts to the Simrel repository).<br />
This patch should be contributed to a new Releng bug that will aggregate all the upcoming releng changes for the next release.<br/><br/><br />
<br />
In order to avoid the disruption on the master branch, i.e. shutting down merges until the release, it is recommended to create a new branch based on the release tag and build the release RCP from it. You will have to create a new job on the Integration Instance (you can base it on the Master-RCP job for convenience but do not forget to change the branch). You will then have to modify some references so as to build/integrate against the release and not the nightly:<br />
* '''papyrus.repo.main''' should point on the release (do no forget to either change or delete the override in the RCP job itself.<br />
* '''papyrus.repo.toolsmiths''' can be updated as well depending on what you are including in the RCP.<br />
<br />
The old textual release refenreces should also be updated to the new one as well as the splash screen. To that effect there is an updatable svg in the org.eclipse.papyrus.rcp plugin. From this svg you will be able to generate the required ''splash.bmp'' file; do not forget however that the file should not exceed 400 kBs.<br />
You will need to be aware of the limitations mentioned in the following [https://wiki.eclipse.org/Platform-releng/Updating_Branding#Splash_screen eclipse branding page].<br />
<br />
Once all that is done you would be able to use the Publish-RCP job that will take care of the rest for you. Once the RCPs are on the eclipse servers a final check on the sum and integrity of the archive should be done and you are all set.<br />
<br />
=== Preparing the release ===<br />
<br />
To prepare the official release, the final build will have to be copied from <code>milestones/<versionnumber>/<RCx></code> to <code>releases/<versionname>/<releasenumber>/</code> (e.g. ''cp -r ./milestones/2.0/RC4/. ./releases/neon/2.0.2/''). This will allow the indexing of the future release and start the mirroring process.<br/><br />
The copied content should be [https://wiki.eclipse.org/SimRel/Simultaneous_Release_FAQ#How_is_a_final_build_made_.22invisible.22_until_release.3F '''hidden'''] from the installers to synchronize the release with the train. This can be done through the Papyrus-Web repository by adding the new release to the ''hiddenBuilds'' list and adding an empty index.html file to the folder to prevent users from browsing through the server links.<br />
You should also start to remove/archive old milestone build as they are not needed anymore and take space (see [https://wiki.eclipse.org/Papyrus/Papyrus_Developer_Guide/Release_Process:_How_To#Maintenance Maintenance]). You can keep the RC builds if you have to but that's about it. Do not forget to remove the references contained in the composites (artifact and content).<br />
<br />
To do this you will have to log yourself to the '''build.eclipse.org''' repository via an ssh connection (e.g. ''ssh <login>@build.eclipse.org'').<br />
<br />
=== Papyrus Web page ===<br />
*Prepare a patch with the updated News and Downloads page in order to push them the day of the release. For this you will have to fetch the papyrus-Web repository [http://git.eclipse.org/c/www.eclipse.org/papyrus.git/ here].<br />
*Update the news, the RCP references and the releases/nightly references provided by the news.xml and download.html for the static page and from there you should be set.<br />
*Update relatives</div>Patrick.Tessier.cea.frhttps://wiki.eclipse.org/index.php?title=Installation_steps_of_Papyrus_for_Requirements&diff=445677Installation steps of Papyrus for Requirements2022-07-18T12:34:23Z<p>Patrick.Tessier.cea.fr: Replaced content with "outdated"</p>
<hr />
<div>outdated</div>Patrick.Tessier.cea.frhttps://wiki.eclipse.org/index.php?title=Papyrus&diff=444284Papyrus2021-11-18T13:34:34Z<p>Patrick.Tessier.cea.fr: /* Current tasks */</p>
<hr />
<div>=Overview=<br />
[https://eclipse.org/papyrus/ Papyrus] is an open source project to provide an integrated environment for editing [[MDT-UML2|UML]] and [https://www.eclipse.org/papyrus/components/sysml/ SysML] models. Specially, this project provides the glue around valuable UML and SysML diagram editors ([[GMF]]-based or not) and other MDE tools. It also offers support for UML and SysML profiling mechanisms. <br />
<br />
You can explore Papyrus's galaxy here [https://eclipse.org/papyrus/ https://eclipse.org/papyrus/].<br />
<br />
=Documentation=<br />
<br />
* Initial project description : [[MDT/Papyrus-Proposal | Papyrus component proposal]]<br />
* Guides<br />
** [https://help.eclipse.org/2021-03/index.jsp?nav=%2F73_0 Papyrus User Guide]<br />
** [[Papyrus User Guide|User Guide]]<br />
** [[Papyrus/Papyrus Developer Guide | Developer Guide]]<br />
* Migration Guides<br />
** [[Papyrus/Migration Guide/Oxygen | Papyrus Oxygen (3.0) Migration Guide]]<br />
** [[Papyrus/Migration Guide/Neon | Papyrus Neon (2.0) Migration Guide]] — [[Media:Papyrus_Neon_Migration_Guide.pdf|as printable PDF]]<br />
<br />
<!--* Miscellaneous<br />
** [[General Architecture | General Architecture]]<br />
** [[Eclipse Papyrus FAQ|Eclipse Papyrus FAQ]]--><br />
<br />
=Papyrus Ecosystems=<br />
Informations about Papyrus relatives components are available [https://www.eclipse.org/papyrus/relatives.html here]<br />
<br />
* Papyrus4<br />
** [[Papyrus for Information Modeling | Papyrus4Information Modeling ]]<br />
** [[Papyrus for Education | Papyrus4Education]]<br />
* [https://www.eclipse.org/papyrus/relatives.html Papyrus Relatives]<br />
** [https://wiki.eclipse.org/Papyrus/UserGuide/ModelExecution Moka]<br />
<br />
=Road Map and Tasks=<br />
==Last news==<br />
* Papyrus 5.2 (Eclipse 2021-09) is available!<br />
* Integration problem<br />
Due to XWT integration issues, we were unable to post on time on the 2021-12 eclipse stream. However, we are going to carry out the RCP and update site in the coming weeks.<br />
<br />
== Current tasks==<br />
* We are improving customization tools to be able validate customization models of the property view<br />
* We are adding new 3 diagrams implantation (class, state machine, sequence) based on Sirius technologies. To benefit of these diagrams, a module like relatives should be chosen.<br />
<br />
==About Releases (6.X)==<br />
<br />
* [[Papyrus/2021.12 Work Description | Incoming work for 2021.12]]<br />
<br />
==About Releases (5.X)==<br />
<br />
* [[Papyrus/2020.12 Work Description | Incoming work for 2020.12]]<br />
* [[Papyrus/2021.03 Work Description | Incoming work for 2021.03]]<br />
* [[Papyrus/2021.09 Work Description | Incoming work for 2021.09]]<br />
<br />
==About Releases (4.X)==<br />
* [[Papyrus/2020.06 Work Description | Incoming work for 2020.06]]<br />
* [[Papyrus/2020.03 Work Description | Incoming work for 2020.03]]<br />
* [[Papyrus/2019.12 Work Description | Incoming work for 2019.12]]<br />
* [[Papyrus/2019.09 Work Description | Incoming work for 2019.09]]<br />
* [[Papyrus/2019.06 Work Description | Incoming work for 2019.06]]<br />
* [[Papyrus/2019.03 Work Description | Incoming work for 2019.03]]<br />
* [[Papyrus/2018.12 Work Description | Incoming work for 2018.12]]<br />
* [[Papyrus/2018.9 Work Description | Incoming work for 2018.9]]<br />
* [[Papyrus/Photon Work Description | Incoming work for Photon]]<br />
<br />
<br />
* [[Papyrus/Archives | Incoming works for previous releases]]<br />
<br />
=Team=<br />
The project committers are:<br />
* Ansgar Radermacher (CEA)<br />
* Camille Letavernier (EclipseSource) <br />
* Christian W. Damus (independant)<br />
* Florian Noyrit (CEA)<br />
* Jeremie Tatibouet (CEA)<br />
* Patrick Tessier (CEA)<br />
* Pauline Deville (CEA)<br />
* Quentin Le Menez (CEA)<br />
* Remi Schnekenburger (EclipseSource) <br />
* Shuai Li (CEA)<br />
* Vincent Lorenzo (CEA)<br />
<br />
<br/>Committers Emeritus:<br />
* Arnaud Cuccuru (CEA)<br />
* Arthur Daussy (ATOS)<br />
* Benoit Maggi (independant)<br />
* Cedric Dumoulin (LIFL)<br />
* Chokri Mraidha (CEA)<br />
* Juan Cadavid (CEA)<br />
* Mickael Adam (All4Tec)<br />
* Nicolas Fauvergue (independant)<br />
* Raphael Faudou (Samares)<br />
* Saadia Dhouib (CEA)<br />
* Sebastien Gerard (CEA – Project lead)<br />
* Tristan Faure (independant)<br />
<br />
=Contacts= <br />
<br />
You can browse the Papyrus git repositories at [https://git.eclipse.org/c/papyrus/ https://git.eclipse.org/c/papyrus/].<br />
<br />
Any issue should be reported using [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Papyrus Bugzilla].<br />
<br />
You may also contact the team using forums or mailing list:<br />
* [http://www.eclipse.org/forums/index.php?t=thread&frm_id=121 Papyrus forums]<br />
* [https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev Developer Mailing List] ([https://dev.eclipse.org/mhonarc/lists/mdt-papyrus.dev/ Mailing list Archive])<br />
<br />
<br />
[[Category:Modeling]]<br />
[[Category:Papyrus]]</div>Patrick.Tessier.cea.frhttps://wiki.eclipse.org/index.php?title=Papyrus&diff=444283Papyrus2021-11-18T13:33:14Z<p>Patrick.Tessier.cea.fr: /* Current tasks */</p>
<hr />
<div>=Overview=<br />
[https://eclipse.org/papyrus/ Papyrus] is an open source project to provide an integrated environment for editing [[MDT-UML2|UML]] and [https://www.eclipse.org/papyrus/components/sysml/ SysML] models. Specially, this project provides the glue around valuable UML and SysML diagram editors ([[GMF]]-based or not) and other MDE tools. It also offers support for UML and SysML profiling mechanisms. <br />
<br />
You can explore Papyrus's galaxy here [https://eclipse.org/papyrus/ https://eclipse.org/papyrus/].<br />
<br />
=Documentation=<br />
<br />
* Initial project description : [[MDT/Papyrus-Proposal | Papyrus component proposal]]<br />
* Guides<br />
** [https://help.eclipse.org/2021-03/index.jsp?nav=%2F73_0 Papyrus User Guide]<br />
** [[Papyrus User Guide|User Guide]]<br />
** [[Papyrus/Papyrus Developer Guide | Developer Guide]]<br />
* Migration Guides<br />
** [[Papyrus/Migration Guide/Oxygen | Papyrus Oxygen (3.0) Migration Guide]]<br />
** [[Papyrus/Migration Guide/Neon | Papyrus Neon (2.0) Migration Guide]] — [[Media:Papyrus_Neon_Migration_Guide.pdf|as printable PDF]]<br />
<br />
<!--* Miscellaneous<br />
** [[General Architecture | General Architecture]]<br />
** [[Eclipse Papyrus FAQ|Eclipse Papyrus FAQ]]--><br />
<br />
=Papyrus Ecosystems=<br />
Informations about Papyrus relatives components are available [https://www.eclipse.org/papyrus/relatives.html here]<br />
<br />
* Papyrus4<br />
** [[Papyrus for Information Modeling | Papyrus4Information Modeling ]]<br />
** [[Papyrus for Education | Papyrus4Education]]<br />
* [https://www.eclipse.org/papyrus/relatives.html Papyrus Relatives]<br />
** [https://wiki.eclipse.org/Papyrus/UserGuide/ModelExecution Moka]<br />
<br />
=Road Map and Tasks=<br />
==Last news==<br />
* Papyrus 5.2 (Eclipse 2021-09) is available!<br />
* Integration problem<br />
Due to XWT integration issues, we were unable to post on time on the 2021-12 eclipse stream. However, we are going to carry out the RCP and update site in the coming weeks.<br />
<br />
== Current tasks==<br />
* We improve customization tools to be able validate customization models of the property view<br />
* We rework diagram code to reduce dead code<br />
* We are adding new 3 diagrams implantation (class, state machine, sequence) based on sirius technologies. To benefit of theses diagram, a module like relatives should be chosen.<br />
<br />
==About Releases (6.X)==<br />
<br />
* [[Papyrus/2021.12 Work Description | Incoming work for 2021.12]]<br />
<br />
==About Releases (5.X)==<br />
<br />
* [[Papyrus/2020.12 Work Description | Incoming work for 2020.12]]<br />
* [[Papyrus/2021.03 Work Description | Incoming work for 2021.03]]<br />
* [[Papyrus/2021.09 Work Description | Incoming work for 2021.09]]<br />
<br />
==About Releases (4.X)==<br />
* [[Papyrus/2020.06 Work Description | Incoming work for 2020.06]]<br />
* [[Papyrus/2020.03 Work Description | Incoming work for 2020.03]]<br />
* [[Papyrus/2019.12 Work Description | Incoming work for 2019.12]]<br />
* [[Papyrus/2019.09 Work Description | Incoming work for 2019.09]]<br />
* [[Papyrus/2019.06 Work Description | Incoming work for 2019.06]]<br />
* [[Papyrus/2019.03 Work Description | Incoming work for 2019.03]]<br />
* [[Papyrus/2018.12 Work Description | Incoming work for 2018.12]]<br />
* [[Papyrus/2018.9 Work Description | Incoming work for 2018.9]]<br />
* [[Papyrus/Photon Work Description | Incoming work for Photon]]<br />
<br />
<br />
* [[Papyrus/Archives | Incoming works for previous releases]]<br />
<br />
=Team=<br />
The project committers are:<br />
* Ansgar Radermacher (CEA)<br />
* Camille Letavernier (EclipseSource) <br />
* Christian W. Damus (independant)<br />
* Florian Noyrit (CEA)<br />
* Jeremie Tatibouet (CEA)<br />
* Patrick Tessier (CEA)<br />
* Pauline Deville (CEA)<br />
* Quentin Le Menez (CEA)<br />
* Remi Schnekenburger (EclipseSource) <br />
* Shuai Li (CEA)<br />
* Vincent Lorenzo (CEA)<br />
<br />
<br/>Committers Emeritus:<br />
* Arnaud Cuccuru (CEA)<br />
* Arthur Daussy (ATOS)<br />
* Benoit Maggi (independant)<br />
* Cedric Dumoulin (LIFL)<br />
* Chokri Mraidha (CEA)<br />
* Juan Cadavid (CEA)<br />
* Mickael Adam (All4Tec)<br />
* Nicolas Fauvergue (independant)<br />
* Raphael Faudou (Samares)<br />
* Saadia Dhouib (CEA)<br />
* Sebastien Gerard (CEA – Project lead)<br />
* Tristan Faure (independant)<br />
<br />
=Contacts= <br />
<br />
You can browse the Papyrus git repositories at [https://git.eclipse.org/c/papyrus/ https://git.eclipse.org/c/papyrus/].<br />
<br />
Any issue should be reported using [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Papyrus Bugzilla].<br />
<br />
You may also contact the team using forums or mailing list:<br />
* [http://www.eclipse.org/forums/index.php?t=thread&frm_id=121 Papyrus forums]<br />
* [https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev Developer Mailing List] ([https://dev.eclipse.org/mhonarc/lists/mdt-papyrus.dev/ Mailing list Archive])<br />
<br />
<br />
[[Category:Modeling]]<br />
[[Category:Papyrus]]</div>Patrick.Tessier.cea.frhttps://wiki.eclipse.org/index.php?title=Papyrus/2021.12_Work_Description&diff=444209Papyrus/2021.12 Work Description2021-10-29T12:25:59Z<p>Patrick.Tessier.cea.fr: </p>
<hr />
<div>All the work realized by CEA LIST is sponsored by CEA LIST. All bugs, or feature may be found in the tracker[https://projects.eclipse.org/projects/modeling.mdt.papyrus/releases/6.0.0/bugs] .<br />
<br />
==Papyrus 6.0:==<br />
* we will reduce the dead code in the generated diagram code for GMF by introducing abstract classes.<br />
* we have worked on tools to validate all customization models<br />
* we have added a library to be able to connect a Xtext editor as diagram editor or tbale editor.<br />
* we have added a set of fixed bugs<br />
<br />
Note that all the relatives: Sysml 1.6, Moka, designer... have also been reworked to be compatible with papyrus 6.0.</div>Patrick.Tessier.cea.frhttps://wiki.eclipse.org/index.php?title=Papyrus/2021.12_Work_Description&diff=444208Papyrus/2021.12 Work Description2021-10-29T12:23:53Z<p>Patrick.Tessier.cea.fr: Created page with "All the work realized by CEA LIST is sponsored by CEA LIST. All bugs, or feature may be found in the tracker[https://projects.eclipse.org/projects/modeling.mdt.papyrus/release..."</p>
<hr />
<div>All the work realized by CEA LIST is sponsored by CEA LIST. All bugs, or feature may be found in the tracker[https://projects.eclipse.org/projects/modeling.mdt.papyrus/releases/6.0.0/bugs] .<br />
<br />
Papyrus 6.0:<br />
<br />
-we will reduce the dead code in the generated diagram code for GMF by introducing abstract classes.<br />
-we have worked on tools to validate all customization models<br />
- we have added a library to be able to connect a Xtext editor as diagram editor or tbale editor.<br />
- we have added a set of bug fixed<br />
Note that all the relatives: Sysml 1.6, Moka, designer... have also been reworked to be compatible with papyrus 6.0.</div>Patrick.Tessier.cea.frhttps://wiki.eclipse.org/index.php?title=Papyrus&diff=444207Papyrus2021-10-29T12:22:19Z<p>Patrick.Tessier.cea.fr: /* About Releases (5.X) */</p>
<hr />
<div>=Overview=<br />
[https://eclipse.org/papyrus/ Papyrus] is an open source project to provide an integrated environment for editing [[MDT-UML2|UML]] and [https://www.eclipse.org/papyrus/components/sysml/ SysML] models. Specially, this project provides the glue around valuable UML and SysML diagram editors ([[GMF]]-based or not) and other MDE tools. It also offers support for UML and SysML profiling mechanisms. <br />
<br />
You can explore Papyrus's galaxy here [https://eclipse.org/papyrus/ https://eclipse.org/papyrus/].<br />
<br />
=Documentation=<br />
<br />
* Initial project description : [[MDT/Papyrus-Proposal | Papyrus component proposal]]<br />
* Guides<br />
** [https://help.eclipse.org/2021-03/index.jsp?nav=%2F73_0 Papyrus User Guide]<br />
** [[Papyrus User Guide|User Guide]]<br />
** [[Papyrus/Papyrus Developer Guide | Developer Guide]]<br />
* Migration Guides<br />
** [[Papyrus/Migration Guide/Oxygen | Papyrus Oxygen (3.0) Migration Guide]]<br />
** [[Papyrus/Migration Guide/Neon | Papyrus Neon (2.0) Migration Guide]] — [[Media:Papyrus_Neon_Migration_Guide.pdf|as printable PDF]]<br />
<br />
<!--* Miscellaneous<br />
** [[General Architecture | General Architecture]]<br />
** [[Eclipse Papyrus FAQ|Eclipse Papyrus FAQ]]--><br />
<br />
=Papyrus Ecosystems=<br />
Informations about Papyrus relatives components are available [https://www.eclipse.org/papyrus/relatives.html here]<br />
<br />
* Papyrus4<br />
** [[Papyrus for Information Modeling | Papyrus4Information Modeling ]]<br />
** [[Papyrus for Education | Papyrus4Education]]<br />
* [https://www.eclipse.org/papyrus/relatives.html Papyrus Relatives]<br />
** [https://wiki.eclipse.org/Papyrus/UserGuide/ModelExecution Moka]<br />
<br />
=Road Map and Tasks=<br />
==Last news==<br />
* Papyrus 5.2 (Eclipse 2021-09) is available!<br />
* Integration problem<br />
Due to XWT integration issues, we were unable to post on time on the 2021-12 eclipse stream. However, we are going to carry out the RCP and update site in the coming weeks.<br />
<br />
== Current tasks==<br />
* We improve customization tools to be able validate customization models of the property view<br />
* We rework diagram code to reduce dead code<br />
* We add new 3 diagrams implantation (class, state machine, sequence) based on sirius technologies. To benefit of theses diagram, a module like relatives should be chosen.<br />
<br />
==About Releases (6.X)==<br />
<br />
* [[Papyrus/2021.12 Work Description | Incoming work for 2021.12]]<br />
<br />
==About Releases (5.X)==<br />
<br />
* [[Papyrus/2020.12 Work Description | Incoming work for 2020.12]]<br />
* [[Papyrus/2021.03 Work Description | Incoming work for 2021.03]]<br />
* [[Papyrus/2021.09 Work Description | Incoming work for 2021.09]]<br />
<br />
==About Releases (4.X)==<br />
* [[Papyrus/2020.06 Work Description | Incoming work for 2020.06]]<br />
* [[Papyrus/2020.03 Work Description | Incoming work for 2020.03]]<br />
* [[Papyrus/2019.12 Work Description | Incoming work for 2019.12]]<br />
* [[Papyrus/2019.09 Work Description | Incoming work for 2019.09]]<br />
* [[Papyrus/2019.06 Work Description | Incoming work for 2019.06]]<br />
* [[Papyrus/2019.03 Work Description | Incoming work for 2019.03]]<br />
* [[Papyrus/2018.12 Work Description | Incoming work for 2018.12]]<br />
* [[Papyrus/2018.9 Work Description | Incoming work for 2018.9]]<br />
* [[Papyrus/Photon Work Description | Incoming work for Photon]]<br />
<br />
<br />
* [[Papyrus/Archives | Incoming works for previous releases]]<br />
<br />
=Team=<br />
The project committers are:<br />
* Ansgar Radermacher (CEA)<br />
* Camille Letavernier (EclipseSource) <br />
* Christian W. Damus (independant)<br />
* Florian Noyrit (CEA)<br />
* Jeremie Tatibouet (CEA)<br />
* Patrick Tessier (CEA)<br />
* Pauline Deville (CEA)<br />
* Quentin Le Menez (CEA)<br />
* Remi Schnekenburger (EclipseSource) <br />
* Shuai Li (CEA)<br />
* Vincent Lorenzo (CEA)<br />
<br />
<br/>Committers Emeritus:<br />
* Arnaud Cuccuru (CEA)<br />
* Arthur Daussy (ATOS)<br />
* Benoit Maggi (independant)<br />
* Cedric Dumoulin (LIFL)<br />
* Chokri Mraidha (CEA)<br />
* Juan Cadavid (CEA)<br />
* Mickael Adam (All4Tec)<br />
* Nicolas Fauvergue (independant)<br />
* Raphael Faudou (Samares)<br />
* Saadia Dhouib (CEA)<br />
* Sebastien Gerard (CEA – Project lead)<br />
* Tristan Faure (independant)<br />
<br />
=Contacts= <br />
<br />
You can browse the Papyrus git repositories at [https://git.eclipse.org/c/papyrus/ https://git.eclipse.org/c/papyrus/].<br />
<br />
Any issue should be reported using [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Papyrus Bugzilla].<br />
<br />
You may also contact the team using forums or mailing list:<br />
* [http://www.eclipse.org/forums/index.php?t=thread&frm_id=121 Papyrus forums]<br />
* [https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev Developer Mailing List] ([https://dev.eclipse.org/mhonarc/lists/mdt-papyrus.dev/ Mailing list Archive])<br />
<br />
<br />
[[Category:Modeling]]<br />
[[Category:Papyrus]]</div>Patrick.Tessier.cea.frhttps://wiki.eclipse.org/index.php?title=Papyrus&diff=444002Papyrus2021-09-22T10:03:08Z<p>Patrick.Tessier.cea.fr: /* Documentation */</p>
<hr />
<div>=Overview=<br />
[https://eclipse.org/papyrus/ Papyrus] is an open source project to provide an integrated environment for editing [[MDT-UML2|UML]] and [https://www.eclipse.org/papyrus/components/sysml/ SysML] models. Specially, this project provides the glue around valuable UML and SysML diagram editors ([[GMF]]-based or not) and other MDE tools. It also offers support for UML and SysML profiling mechanisms. <br />
<br />
You can explore Papyrus's galaxy here [https://eclipse.org/papyrus/ https://eclipse.org/papyrus/].<br />
<br />
=Documentation=<br />
<br />
* Initial project description : [[MDT/Papyrus-Proposal | Papyrus component proposal]]<br />
* Guides<br />
** [https://help.eclipse.org/2021-03/index.jsp?nav=%2F73_0 Papyrus User Guide]<br />
** [[Papyrus User Guide|User Guide]]<br />
** [[Papyrus/Papyrus Developer Guide | Developer Guide]]<br />
* Migration Guides<br />
** [[Papyrus/Migration Guide/Oxygen | Papyrus Oxygen (3.0) Migration Guide]]<br />
** [[Papyrus/Migration Guide/Neon | Papyrus Neon (2.0) Migration Guide]] — [[Media:Papyrus_Neon_Migration_Guide.pdf|as printable PDF]]<br />
<br />
<!--* Miscellaneous<br />
** [[General Architecture | General Architecture]]<br />
** [[Eclipse Papyrus FAQ|Eclipse Papyrus FAQ]]--><br />
<br />
=Papyrus Ecosystems=<br />
Informations about Papyrus relatives components are available [https://www.eclipse.org/papyrus/relatives.html here]<br />
<br />
* Papyrus4<br />
** [[Papyrus for Information Modeling | Papyrus4Information Modeling ]]<br />
** [[Papyrus for Education | Papyrus4Education]]<br />
* [https://www.eclipse.org/papyrus/relatives.html Papyrus Relatives]<br />
** [https://wiki.eclipse.org/Papyrus/UserGuide/ModelExecution Moka]<br />
<br />
=Road Map and Tasks=<br />
==Last news==<br />
* Papyrus 5.2 (Eclipse 2021-09) is available!<br />
* Integration problem<br />
Due to XWT integration issues, we were unable to post on time on the 2021-12 eclipse stream. However, we are going to carry out the RCP and update site in the coming weeks.<br />
<br />
== Current tasks==<br />
* We improve customization tools to be able validate customization models of the property view<br />
* We rework diagram code to reduce dead code<br />
* We add new 3 diagrams implantation (class, state machine, sequence) based on sirius technologies. To benefit of theses diagram, a module like relatives should be chosen.<br />
<br />
==About Releases (5.X)==<br />
<br />
* [[Papyrus/2020.12 Work Description | Incoming work for 2020.12]]<br />
* [[Papyrus/2021.03 Work Description | Incoming work for 2021.03]]<br />
* [[Papyrus/2021.09 Work Description | Incoming work for 2021.09]]<br />
<br />
==About Releases (4.X)==<br />
* [[Papyrus/2020.06 Work Description | Incoming work for 2020.06]]<br />
* [[Papyrus/2020.03 Work Description | Incoming work for 2020.03]]<br />
* [[Papyrus/2019.12 Work Description | Incoming work for 2019.12]]<br />
* [[Papyrus/2019.09 Work Description | Incoming work for 2019.09]]<br />
* [[Papyrus/2019.06 Work Description | Incoming work for 2019.06]]<br />
* [[Papyrus/2019.03 Work Description | Incoming work for 2019.03]]<br />
* [[Papyrus/2018.12 Work Description | Incoming work for 2018.12]]<br />
* [[Papyrus/2018.9 Work Description | Incoming work for 2018.9]]<br />
* [[Papyrus/Photon Work Description | Incoming work for Photon]]<br />
<br />
<br />
* [[Papyrus/Archives | Incoming works for previous releases]]<br />
<br />
=Team=<br />
The project committers are:<br />
* Ansgar Radermacher (CEA)<br />
* Camille Letavernier (EclipseSource) <br />
* Christian W. Damus (independant)<br />
* Florian Noyrit (CEA)<br />
* Jeremie Tatibouet (CEA)<br />
* Patrick Tessier (CEA)<br />
* Pauline Deville (CEA)<br />
* Quentin Le Menez (CEA)<br />
* Remi Schnekenburger (EclipseSource) <br />
* Shuai Li (CEA)<br />
* Vincent Lorenzo (CEA)<br />
<br />
<br/>Committers Emeritus:<br />
* Arnaud Cuccuru (CEA)<br />
* Arthur Daussy (ATOS)<br />
* Benoit Maggi (independant)<br />
* Cedric Dumoulin (LIFL)<br />
* Chokri Mraidha (CEA)<br />
* Juan Cadavid (CEA)<br />
* Mickael Adam (All4Tec)<br />
* Nicolas Fauvergue (independant)<br />
* Raphael Faudou (Samares)<br />
* Saadia Dhouib (CEA)<br />
* Sebastien Gerard (CEA – Project lead)<br />
* Tristan Faure (independant)<br />
<br />
=Contacts= <br />
<br />
You can browse the Papyrus git repositories at [https://git.eclipse.org/c/papyrus/ https://git.eclipse.org/c/papyrus/].<br />
<br />
Any issue should be reported using [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Papyrus Bugzilla].<br />
<br />
You may also contact the team using forums or mailing list:<br />
* [http://www.eclipse.org/forums/index.php?t=thread&frm_id=121 Papyrus forums]<br />
* [https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev Developer Mailing List] ([https://dev.eclipse.org/mhonarc/lists/mdt-papyrus.dev/ Mailing list Archive])<br />
<br />
<br />
[[Category:Modeling]]<br />
[[Category:Papyrus]]</div>Patrick.Tessier.cea.frhttps://wiki.eclipse.org/index.php?title=Papyrus&diff=444001Papyrus2021-09-22T10:00:34Z<p>Patrick.Tessier.cea.fr: /* Last news */</p>
<hr />
<div>=Overview=<br />
[https://eclipse.org/papyrus/ Papyrus] is an open source project to provide an integrated environment for editing [[MDT-UML2|UML]] and [https://www.eclipse.org/papyrus/components/sysml/ SysML] models. Specially, this project provides the glue around valuable UML and SysML diagram editors ([[GMF]]-based or not) and other MDE tools. It also offers support for UML and SysML profiling mechanisms. <br />
<br />
You can explore Papyrus's galaxy here [https://eclipse.org/papyrus/ https://eclipse.org/papyrus/].<br />
<br />
=Documentation=<br />
<br />
* Initial project description : [[MDT/Papyrus-Proposal | Papyrus component proposal]]<br />
* Guides<br />
** [https://help.eclipse.org/2020-09/index.jsp?nav=%2F73_0 2020/09 Papyrus User Guide]<br />
** [[Papyrus User Guide|User Guide]]<br />
** [[Papyrus/Papyrus Developer Guide | Developer Guide]]<br />
* Migration Guides<br />
** [[Papyrus/Migration Guide/Oxygen | Papyrus Oxygen (3.0) Migration Guide]]<br />
** [[Papyrus/Migration Guide/Neon | Papyrus Neon (2.0) Migration Guide]] — [[Media:Papyrus_Neon_Migration_Guide.pdf|as printable PDF]]<br />
<br />
<!--* Miscellaneous<br />
** [[General Architecture | General Architecture]]<br />
** [[Eclipse Papyrus FAQ|Eclipse Papyrus FAQ]]--><br />
<br />
=Papyrus Ecosystems=<br />
Informations about Papyrus relatives components are available [https://www.eclipse.org/papyrus/relatives.html here]<br />
<br />
* Papyrus4<br />
** [[Papyrus for Information Modeling | Papyrus4Information Modeling ]]<br />
** [[Papyrus for Education | Papyrus4Education]]<br />
* [https://www.eclipse.org/papyrus/relatives.html Papyrus Relatives]<br />
** [https://wiki.eclipse.org/Papyrus/UserGuide/ModelExecution Moka]<br />
<br />
=Road Map and Tasks=<br />
==Last news==<br />
* Papyrus 5.2 (Eclipse 2021-09) is available!<br />
* Integration problem<br />
Due to XWT integration issues, we were unable to post on time on the 2021-12 eclipse stream. However, we are going to carry out the RCP and update site in the coming weeks.<br />
<br />
== Current tasks==<br />
* We improve customization tools to be able validate customization models of the property view<br />
* We rework diagram code to reduce dead code<br />
* We add new 3 diagrams implantation (class, state machine, sequence) based on sirius technologies. To benefit of theses diagram, a module like relatives should be chosen.<br />
<br />
==About Releases (5.X)==<br />
<br />
* [[Papyrus/2020.12 Work Description | Incoming work for 2020.12]]<br />
* [[Papyrus/2021.03 Work Description | Incoming work for 2021.03]]<br />
* [[Papyrus/2021.09 Work Description | Incoming work for 2021.09]]<br />
<br />
==About Releases (4.X)==<br />
* [[Papyrus/2020.06 Work Description | Incoming work for 2020.06]]<br />
* [[Papyrus/2020.03 Work Description | Incoming work for 2020.03]]<br />
* [[Papyrus/2019.12 Work Description | Incoming work for 2019.12]]<br />
* [[Papyrus/2019.09 Work Description | Incoming work for 2019.09]]<br />
* [[Papyrus/2019.06 Work Description | Incoming work for 2019.06]]<br />
* [[Papyrus/2019.03 Work Description | Incoming work for 2019.03]]<br />
* [[Papyrus/2018.12 Work Description | Incoming work for 2018.12]]<br />
* [[Papyrus/2018.9 Work Description | Incoming work for 2018.9]]<br />
* [[Papyrus/Photon Work Description | Incoming work for Photon]]<br />
<br />
<br />
* [[Papyrus/Archives | Incoming works for previous releases]]<br />
<br />
=Team=<br />
The project committers are:<br />
* Ansgar Radermacher (CEA)<br />
* Camille Letavernier (EclipseSource) <br />
* Christian W. Damus (independant)<br />
* Florian Noyrit (CEA)<br />
* Jeremie Tatibouet (CEA)<br />
* Patrick Tessier (CEA)<br />
* Pauline Deville (CEA)<br />
* Quentin Le Menez (CEA)<br />
* Remi Schnekenburger (EclipseSource) <br />
* Shuai Li (CEA)<br />
* Vincent Lorenzo (CEA)<br />
<br />
<br/>Committers Emeritus:<br />
* Arnaud Cuccuru (CEA)<br />
* Arthur Daussy (ATOS)<br />
* Benoit Maggi (independant)<br />
* Cedric Dumoulin (LIFL)<br />
* Chokri Mraidha (CEA)<br />
* Juan Cadavid (CEA)<br />
* Mickael Adam (All4Tec)<br />
* Nicolas Fauvergue (independant)<br />
* Raphael Faudou (Samares)<br />
* Saadia Dhouib (CEA)<br />
* Sebastien Gerard (CEA – Project lead)<br />
* Tristan Faure (independant)<br />
<br />
=Contacts= <br />
<br />
You can browse the Papyrus git repositories at [https://git.eclipse.org/c/papyrus/ https://git.eclipse.org/c/papyrus/].<br />
<br />
Any issue should be reported using [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Papyrus Bugzilla].<br />
<br />
You may also contact the team using forums or mailing list:<br />
* [http://www.eclipse.org/forums/index.php?t=thread&frm_id=121 Papyrus forums]<br />
* [https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev Developer Mailing List] ([https://dev.eclipse.org/mhonarc/lists/mdt-papyrus.dev/ Mailing list Archive])<br />
<br />
<br />
[[Category:Modeling]]<br />
[[Category:Papyrus]]</div>Patrick.Tessier.cea.frhttps://wiki.eclipse.org/index.php?title=Papyrus&diff=444000Papyrus2021-09-22T09:59:55Z<p>Patrick.Tessier.cea.fr: /* About Releases (5.X) */</p>
<hr />
<div>=Overview=<br />
[https://eclipse.org/papyrus/ Papyrus] is an open source project to provide an integrated environment for editing [[MDT-UML2|UML]] and [https://www.eclipse.org/papyrus/components/sysml/ SysML] models. Specially, this project provides the glue around valuable UML and SysML diagram editors ([[GMF]]-based or not) and other MDE tools. It also offers support for UML and SysML profiling mechanisms. <br />
<br />
You can explore Papyrus's galaxy here [https://eclipse.org/papyrus/ https://eclipse.org/papyrus/].<br />
<br />
=Documentation=<br />
<br />
* Initial project description : [[MDT/Papyrus-Proposal | Papyrus component proposal]]<br />
* Guides<br />
** [https://help.eclipse.org/2020-09/index.jsp?nav=%2F73_0 2020/09 Papyrus User Guide]<br />
** [[Papyrus User Guide|User Guide]]<br />
** [[Papyrus/Papyrus Developer Guide | Developer Guide]]<br />
* Migration Guides<br />
** [[Papyrus/Migration Guide/Oxygen | Papyrus Oxygen (3.0) Migration Guide]]<br />
** [[Papyrus/Migration Guide/Neon | Papyrus Neon (2.0) Migration Guide]] — [[Media:Papyrus_Neon_Migration_Guide.pdf|as printable PDF]]<br />
<br />
<!--* Miscellaneous<br />
** [[General Architecture | General Architecture]]<br />
** [[Eclipse Papyrus FAQ|Eclipse Papyrus FAQ]]--><br />
<br />
=Papyrus Ecosystems=<br />
Informations about Papyrus relatives components are available [https://www.eclipse.org/papyrus/relatives.html here]<br />
<br />
* Papyrus4<br />
** [[Papyrus for Information Modeling | Papyrus4Information Modeling ]]<br />
** [[Papyrus for Education | Papyrus4Education]]<br />
* [https://www.eclipse.org/papyrus/relatives.html Papyrus Relatives]<br />
** [https://wiki.eclipse.org/Papyrus/UserGuide/ModelExecution Moka]<br />
<br />
=Road Map and Tasks=<br />
==Last news==<br />
* papyrus 5.2 is available!<br />
* Integration problem<br />
Due to XWT integration issues, we were unable to post on time on the 2021-12 eclipse stream. However, we are going to carry out the RCP and update site in the coming weeks.<br />
<br />
== Current tasks==<br />
* We improve customization tools to be able validate customization models of the property view<br />
* We rework diagram code to reduce dead code<br />
* We add new 3 diagrams implantation (class, state machine, sequence) based on sirius technologies. To benefit of theses diagram, a module like relatives should be chosen.<br />
<br />
==About Releases (5.X)==<br />
<br />
* [[Papyrus/2020.12 Work Description | Incoming work for 2020.12]]<br />
* [[Papyrus/2021.03 Work Description | Incoming work for 2021.03]]<br />
* [[Papyrus/2021.09 Work Description | Incoming work for 2021.09]]<br />
<br />
==About Releases (4.X)==<br />
* [[Papyrus/2020.06 Work Description | Incoming work for 2020.06]]<br />
* [[Papyrus/2020.03 Work Description | Incoming work for 2020.03]]<br />
* [[Papyrus/2019.12 Work Description | Incoming work for 2019.12]]<br />
* [[Papyrus/2019.09 Work Description | Incoming work for 2019.09]]<br />
* [[Papyrus/2019.06 Work Description | Incoming work for 2019.06]]<br />
* [[Papyrus/2019.03 Work Description | Incoming work for 2019.03]]<br />
* [[Papyrus/2018.12 Work Description | Incoming work for 2018.12]]<br />
* [[Papyrus/2018.9 Work Description | Incoming work for 2018.9]]<br />
* [[Papyrus/Photon Work Description | Incoming work for Photon]]<br />
<br />
<br />
* [[Papyrus/Archives | Incoming works for previous releases]]<br />
<br />
=Team=<br />
The project committers are:<br />
* Ansgar Radermacher (CEA)<br />
* Camille Letavernier (EclipseSource) <br />
* Christian W. Damus (independant)<br />
* Florian Noyrit (CEA)<br />
* Jeremie Tatibouet (CEA)<br />
* Patrick Tessier (CEA)<br />
* Pauline Deville (CEA)<br />
* Quentin Le Menez (CEA)<br />
* Remi Schnekenburger (EclipseSource) <br />
* Shuai Li (CEA)<br />
* Vincent Lorenzo (CEA)<br />
<br />
<br/>Committers Emeritus:<br />
* Arnaud Cuccuru (CEA)<br />
* Arthur Daussy (ATOS)<br />
* Benoit Maggi (independant)<br />
* Cedric Dumoulin (LIFL)<br />
* Chokri Mraidha (CEA)<br />
* Juan Cadavid (CEA)<br />
* Mickael Adam (All4Tec)<br />
* Nicolas Fauvergue (independant)<br />
* Raphael Faudou (Samares)<br />
* Saadia Dhouib (CEA)<br />
* Sebastien Gerard (CEA – Project lead)<br />
* Tristan Faure (independant)<br />
<br />
=Contacts= <br />
<br />
You can browse the Papyrus git repositories at [https://git.eclipse.org/c/papyrus/ https://git.eclipse.org/c/papyrus/].<br />
<br />
Any issue should be reported using [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Papyrus Bugzilla].<br />
<br />
You may also contact the team using forums or mailing list:<br />
* [http://www.eclipse.org/forums/index.php?t=thread&frm_id=121 Papyrus forums]<br />
* [https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev Developer Mailing List] ([https://dev.eclipse.org/mhonarc/lists/mdt-papyrus.dev/ Mailing list Archive])<br />
<br />
<br />
[[Category:Modeling]]<br />
[[Category:Papyrus]]</div>Patrick.Tessier.cea.frhttps://wiki.eclipse.org/index.php?title=Papyrus&diff=443999Papyrus2021-09-22T09:59:18Z<p>Patrick.Tessier.cea.fr: /* Last news */</p>
<hr />
<div>=Overview=<br />
[https://eclipse.org/papyrus/ Papyrus] is an open source project to provide an integrated environment for editing [[MDT-UML2|UML]] and [https://www.eclipse.org/papyrus/components/sysml/ SysML] models. Specially, this project provides the glue around valuable UML and SysML diagram editors ([[GMF]]-based or not) and other MDE tools. It also offers support for UML and SysML profiling mechanisms. <br />
<br />
You can explore Papyrus's galaxy here [https://eclipse.org/papyrus/ https://eclipse.org/papyrus/].<br />
<br />
=Documentation=<br />
<br />
* Initial project description : [[MDT/Papyrus-Proposal | Papyrus component proposal]]<br />
* Guides<br />
** [https://help.eclipse.org/2020-09/index.jsp?nav=%2F73_0 2020/09 Papyrus User Guide]<br />
** [[Papyrus User Guide|User Guide]]<br />
** [[Papyrus/Papyrus Developer Guide | Developer Guide]]<br />
* Migration Guides<br />
** [[Papyrus/Migration Guide/Oxygen | Papyrus Oxygen (3.0) Migration Guide]]<br />
** [[Papyrus/Migration Guide/Neon | Papyrus Neon (2.0) Migration Guide]] — [[Media:Papyrus_Neon_Migration_Guide.pdf|as printable PDF]]<br />
<br />
<!--* Miscellaneous<br />
** [[General Architecture | General Architecture]]<br />
** [[Eclipse Papyrus FAQ|Eclipse Papyrus FAQ]]--><br />
<br />
=Papyrus Ecosystems=<br />
Informations about Papyrus relatives components are available [https://www.eclipse.org/papyrus/relatives.html here]<br />
<br />
* Papyrus4<br />
** [[Papyrus for Information Modeling | Papyrus4Information Modeling ]]<br />
** [[Papyrus for Education | Papyrus4Education]]<br />
* [https://www.eclipse.org/papyrus/relatives.html Papyrus Relatives]<br />
** [https://wiki.eclipse.org/Papyrus/UserGuide/ModelExecution Moka]<br />
<br />
=Road Map and Tasks=<br />
==Last news==<br />
* papyrus 5.2 is available!<br />
* Integration problem<br />
Due to XWT integration issues, we were unable to post on time on the 2021-12 eclipse stream. However, we are going to carry out the RCP and update site in the coming weeks.<br />
<br />
== Current tasks==<br />
* We improve customization tools to be able validate customization models of the property view<br />
* We rework diagram code to reduce dead code<br />
* We add new 3 diagrams implantation (class, state machine, sequence) based on sirius technologies. To benefit of theses diagram, a module like relatives should be chosen.<br />
<br />
==About Releases (5.X)==<br />
* [[Papyrus/2021.09 Work Description | Incoming work for 2021.09]]<br />
* [[Papyrus/2020.12 Work Description | Incoming work for 2020.12]]<br />
* [[Papyrus/2021.03 Work Description | Incoming work for 2021.03]]<br />
* [[Papyrus/2021.06 Work Description | Incoming work for 2021.06]]<br />
<br />
==About Releases (4.X)==<br />
* [[Papyrus/2020.06 Work Description | Incoming work for 2020.06]]<br />
* [[Papyrus/2020.03 Work Description | Incoming work for 2020.03]]<br />
* [[Papyrus/2019.12 Work Description | Incoming work for 2019.12]]<br />
* [[Papyrus/2019.09 Work Description | Incoming work for 2019.09]]<br />
* [[Papyrus/2019.06 Work Description | Incoming work for 2019.06]]<br />
* [[Papyrus/2019.03 Work Description | Incoming work for 2019.03]]<br />
* [[Papyrus/2018.12 Work Description | Incoming work for 2018.12]]<br />
* [[Papyrus/2018.9 Work Description | Incoming work for 2018.9]]<br />
* [[Papyrus/Photon Work Description | Incoming work for Photon]]<br />
<br />
<br />
* [[Papyrus/Archives | Incoming works for previous releases]]<br />
<br />
=Team=<br />
The project committers are:<br />
* Ansgar Radermacher (CEA)<br />
* Camille Letavernier (EclipseSource) <br />
* Christian W. Damus (independant)<br />
* Florian Noyrit (CEA)<br />
* Jeremie Tatibouet (CEA)<br />
* Patrick Tessier (CEA)<br />
* Pauline Deville (CEA)<br />
* Quentin Le Menez (CEA)<br />
* Remi Schnekenburger (EclipseSource) <br />
* Shuai Li (CEA)<br />
* Vincent Lorenzo (CEA)<br />
<br />
<br/>Committers Emeritus:<br />
* Arnaud Cuccuru (CEA)<br />
* Arthur Daussy (ATOS)<br />
* Benoit Maggi (independant)<br />
* Cedric Dumoulin (LIFL)<br />
* Chokri Mraidha (CEA)<br />
* Juan Cadavid (CEA)<br />
* Mickael Adam (All4Tec)<br />
* Nicolas Fauvergue (independant)<br />
* Raphael Faudou (Samares)<br />
* Saadia Dhouib (CEA)<br />
* Sebastien Gerard (CEA – Project lead)<br />
* Tristan Faure (independant)<br />
<br />
=Contacts= <br />
<br />
You can browse the Papyrus git repositories at [https://git.eclipse.org/c/papyrus/ https://git.eclipse.org/c/papyrus/].<br />
<br />
Any issue should be reported using [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Papyrus Bugzilla].<br />
<br />
You may also contact the team using forums or mailing list:<br />
* [http://www.eclipse.org/forums/index.php?t=thread&frm_id=121 Papyrus forums]<br />
* [https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev Developer Mailing List] ([https://dev.eclipse.org/mhonarc/lists/mdt-papyrus.dev/ Mailing list Archive])<br />
<br />
<br />
[[Category:Modeling]]<br />
[[Category:Papyrus]]</div>Patrick.Tessier.cea.frhttps://wiki.eclipse.org/index.php?title=Papyrus&diff=443998Papyrus2021-09-22T09:58:32Z<p>Patrick.Tessier.cea.fr: /* Current tasks */</p>
<hr />
<div>=Overview=<br />
[https://eclipse.org/papyrus/ Papyrus] is an open source project to provide an integrated environment for editing [[MDT-UML2|UML]] and [https://www.eclipse.org/papyrus/components/sysml/ SysML] models. Specially, this project provides the glue around valuable UML and SysML diagram editors ([[GMF]]-based or not) and other MDE tools. It also offers support for UML and SysML profiling mechanisms. <br />
<br />
You can explore Papyrus's galaxy here [https://eclipse.org/papyrus/ https://eclipse.org/papyrus/].<br />
<br />
=Documentation=<br />
<br />
* Initial project description : [[MDT/Papyrus-Proposal | Papyrus component proposal]]<br />
* Guides<br />
** [https://help.eclipse.org/2020-09/index.jsp?nav=%2F73_0 2020/09 Papyrus User Guide]<br />
** [[Papyrus User Guide|User Guide]]<br />
** [[Papyrus/Papyrus Developer Guide | Developer Guide]]<br />
* Migration Guides<br />
** [[Papyrus/Migration Guide/Oxygen | Papyrus Oxygen (3.0) Migration Guide]]<br />
** [[Papyrus/Migration Guide/Neon | Papyrus Neon (2.0) Migration Guide]] — [[Media:Papyrus_Neon_Migration_Guide.pdf|as printable PDF]]<br />
<br />
<!--* Miscellaneous<br />
** [[General Architecture | General Architecture]]<br />
** [[Eclipse Papyrus FAQ|Eclipse Papyrus FAQ]]--><br />
<br />
=Papyrus Ecosystems=<br />
Informations about Papyrus relatives components are available [https://www.eclipse.org/papyrus/relatives.html here]<br />
<br />
* Papyrus4<br />
** [[Papyrus for Information Modeling | Papyrus4Information Modeling ]]<br />
** [[Papyrus for Education | Papyrus4Education]]<br />
* [https://www.eclipse.org/papyrus/relatives.html Papyrus Relatives]<br />
** [https://wiki.eclipse.org/Papyrus/UserGuide/ModelExecution Moka]<br />
<br />
=Road Map and Tasks=<br />
==Last news==<br />
<br />
* Integration problem<br />
Due to XWT integration issues, we were unable to post on time on the 2021-12 eclipse stream. However, we are going to carry out the RCP and update site in the coming weeks.<br />
<br />
== Current tasks==<br />
* We improve customization tools to be able validate customization models of the property view<br />
* We rework diagram code to reduce dead code<br />
* We add new 3 diagrams implantation (class, state machine, sequence) based on sirius technologies. To benefit of theses diagram, a module like relatives should be chosen.<br />
<br />
==About Releases (5.X)==<br />
* [[Papyrus/2021.09 Work Description | Incoming work for 2021.09]]<br />
* [[Papyrus/2020.12 Work Description | Incoming work for 2020.12]]<br />
* [[Papyrus/2021.03 Work Description | Incoming work for 2021.03]]<br />
* [[Papyrus/2021.06 Work Description | Incoming work for 2021.06]]<br />
<br />
==About Releases (4.X)==<br />
* [[Papyrus/2020.06 Work Description | Incoming work for 2020.06]]<br />
* [[Papyrus/2020.03 Work Description | Incoming work for 2020.03]]<br />
* [[Papyrus/2019.12 Work Description | Incoming work for 2019.12]]<br />
* [[Papyrus/2019.09 Work Description | Incoming work for 2019.09]]<br />
* [[Papyrus/2019.06 Work Description | Incoming work for 2019.06]]<br />
* [[Papyrus/2019.03 Work Description | Incoming work for 2019.03]]<br />
* [[Papyrus/2018.12 Work Description | Incoming work for 2018.12]]<br />
* [[Papyrus/2018.9 Work Description | Incoming work for 2018.9]]<br />
* [[Papyrus/Photon Work Description | Incoming work for Photon]]<br />
<br />
<br />
* [[Papyrus/Archives | Incoming works for previous releases]]<br />
<br />
=Team=<br />
The project committers are:<br />
* Ansgar Radermacher (CEA)<br />
* Camille Letavernier (EclipseSource) <br />
* Christian W. Damus (independant)<br />
* Florian Noyrit (CEA)<br />
* Jeremie Tatibouet (CEA)<br />
* Patrick Tessier (CEA)<br />
* Pauline Deville (CEA)<br />
* Quentin Le Menez (CEA)<br />
* Remi Schnekenburger (EclipseSource) <br />
* Shuai Li (CEA)<br />
* Vincent Lorenzo (CEA)<br />
<br />
<br/>Committers Emeritus:<br />
* Arnaud Cuccuru (CEA)<br />
* Arthur Daussy (ATOS)<br />
* Benoit Maggi (independant)<br />
* Cedric Dumoulin (LIFL)<br />
* Chokri Mraidha (CEA)<br />
* Juan Cadavid (CEA)<br />
* Mickael Adam (All4Tec)<br />
* Nicolas Fauvergue (independant)<br />
* Raphael Faudou (Samares)<br />
* Saadia Dhouib (CEA)<br />
* Sebastien Gerard (CEA – Project lead)<br />
* Tristan Faure (independant)<br />
<br />
=Contacts= <br />
<br />
You can browse the Papyrus git repositories at [https://git.eclipse.org/c/papyrus/ https://git.eclipse.org/c/papyrus/].<br />
<br />
Any issue should be reported using [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Papyrus Bugzilla].<br />
<br />
You may also contact the team using forums or mailing list:<br />
* [http://www.eclipse.org/forums/index.php?t=thread&frm_id=121 Papyrus forums]<br />
* [https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev Developer Mailing List] ([https://dev.eclipse.org/mhonarc/lists/mdt-papyrus.dev/ Mailing list Archive])<br />
<br />
<br />
[[Category:Modeling]]<br />
[[Category:Papyrus]]</div>Patrick.Tessier.cea.frhttps://wiki.eclipse.org/index.php?title=Papyrus/2021.09_Work_Description&diff=443997Papyrus/2021.09 Work Description2021-09-22T09:40:40Z<p>Patrick.Tessier.cea.fr: Created page with "Papyrus 5.2 is available: This version is not in the pipeline, but we are back for version 2021.12 which you can download on the following page: https://www.eclipse.org/papyr..."</p>
<hr />
<div>Papyrus 5.2 is available:<br />
<br />
This version is not in the pipeline, but we are back for version 2021.12 which you can download on the following page: https://www.eclipse.org/papyrus/download.html<br />
<br />
This version contains improvements to customize Papyrus:<br />
*A dedicated compiler and a papyrus project nature allows:<br />
**Validate plugins containing profiles<br />
***Validate plugins containing architecture framework<br />
***Validate plugins containing element Type files<br />
***Validate plugins containing newchild model (newchild menu of the model explorer).<br />
***This tool allows you to modify all these artifacts incrementally<br />
**The use of the compiler is documented.<br />
**Papyrus also contains documentation on use cases to implement Type elements.<br />
**Memory leaks have also been corrected.</div>Patrick.Tessier.cea.frhttps://wiki.eclipse.org/index.php?title=Papyrus&diff=443996Papyrus2021-09-22T09:27:12Z<p>Patrick.Tessier.cea.fr: /* About Releases (5.X) */</p>
<hr />
<div>=Overview=<br />
[https://eclipse.org/papyrus/ Papyrus] is an open source project to provide an integrated environment for editing [[MDT-UML2|UML]] and [https://www.eclipse.org/papyrus/components/sysml/ SysML] models. Specially, this project provides the glue around valuable UML and SysML diagram editors ([[GMF]]-based or not) and other MDE tools. It also offers support for UML and SysML profiling mechanisms. <br />
<br />
You can explore Papyrus's galaxy here [https://eclipse.org/papyrus/ https://eclipse.org/papyrus/].<br />
<br />
=Documentation=<br />
<br />
* Initial project description : [[MDT/Papyrus-Proposal | Papyrus component proposal]]<br />
* Guides<br />
** [https://help.eclipse.org/2020-09/index.jsp?nav=%2F73_0 2020/09 Papyrus User Guide]<br />
** [[Papyrus User Guide|User Guide]]<br />
** [[Papyrus/Papyrus Developer Guide | Developer Guide]]<br />
* Migration Guides<br />
** [[Papyrus/Migration Guide/Oxygen | Papyrus Oxygen (3.0) Migration Guide]]<br />
** [[Papyrus/Migration Guide/Neon | Papyrus Neon (2.0) Migration Guide]] — [[Media:Papyrus_Neon_Migration_Guide.pdf|as printable PDF]]<br />
<br />
<!--* Miscellaneous<br />
** [[General Architecture | General Architecture]]<br />
** [[Eclipse Papyrus FAQ|Eclipse Papyrus FAQ]]--><br />
<br />
=Papyrus Ecosystems=<br />
Informations about Papyrus relatives components are available [https://www.eclipse.org/papyrus/relatives.html here]<br />
<br />
* Papyrus4<br />
** [[Papyrus for Information Modeling | Papyrus4Information Modeling ]]<br />
** [[Papyrus for Education | Papyrus4Education]]<br />
* [https://www.eclipse.org/papyrus/relatives.html Papyrus Relatives]<br />
** [https://wiki.eclipse.org/Papyrus/UserGuide/ModelExecution Moka]<br />
<br />
=Road Map and Tasks=<br />
==Last news==<br />
<br />
* Integration problem<br />
Due to XWT integration issues, we were unable to post on time on the 2021-12 eclipse stream. However, we are going to carry out the RCP and update site in the coming weeks.<br />
<br />
== Current tasks==<br />
* We improve customization tools to be able validate customization models and to faster your customization work<br />
* We rework diagram code to reduce dead code<br />
* We add new 3 diagrams implantation (class, state machine, sequence) based on sirius technologies. To benefit of theses diagram, a module like relatives should be chosen.<br />
<br />
==About Releases (5.X)==<br />
* [[Papyrus/2021.09 Work Description | Incoming work for 2021.09]]<br />
* [[Papyrus/2020.12 Work Description | Incoming work for 2020.12]]<br />
* [[Papyrus/2021.03 Work Description | Incoming work for 2021.03]]<br />
* [[Papyrus/2021.06 Work Description | Incoming work for 2021.06]]<br />
<br />
==About Releases (4.X)==<br />
* [[Papyrus/2020.06 Work Description | Incoming work for 2020.06]]<br />
* [[Papyrus/2020.03 Work Description | Incoming work for 2020.03]]<br />
* [[Papyrus/2019.12 Work Description | Incoming work for 2019.12]]<br />
* [[Papyrus/2019.09 Work Description | Incoming work for 2019.09]]<br />
* [[Papyrus/2019.06 Work Description | Incoming work for 2019.06]]<br />
* [[Papyrus/2019.03 Work Description | Incoming work for 2019.03]]<br />
* [[Papyrus/2018.12 Work Description | Incoming work for 2018.12]]<br />
* [[Papyrus/2018.9 Work Description | Incoming work for 2018.9]]<br />
* [[Papyrus/Photon Work Description | Incoming work for Photon]]<br />
<br />
<br />
* [[Papyrus/Archives | Incoming works for previous releases]]<br />
<br />
=Team=<br />
The project committers are:<br />
* Ansgar Radermacher (CEA)<br />
* Camille Letavernier (EclipseSource) <br />
* Christian W. Damus (independant)<br />
* Florian Noyrit (CEA)<br />
* Jeremie Tatibouet (CEA)<br />
* Patrick Tessier (CEA)<br />
* Pauline Deville (CEA)<br />
* Quentin Le Menez (CEA)<br />
* Remi Schnekenburger (EclipseSource) <br />
* Shuai Li (CEA)<br />
* Vincent Lorenzo (CEA)<br />
<br />
<br/>Committers Emeritus:<br />
* Arnaud Cuccuru (CEA)<br />
* Arthur Daussy (ATOS)<br />
* Benoit Maggi (independant)<br />
* Cedric Dumoulin (LIFL)<br />
* Chokri Mraidha (CEA)<br />
* Juan Cadavid (CEA)<br />
* Mickael Adam (All4Tec)<br />
* Nicolas Fauvergue (independant)<br />
* Raphael Faudou (Samares)<br />
* Saadia Dhouib (CEA)<br />
* Sebastien Gerard (CEA – Project lead)<br />
* Tristan Faure (independant)<br />
<br />
=Contacts= <br />
<br />
You can browse the Papyrus git repositories at [https://git.eclipse.org/c/papyrus/ https://git.eclipse.org/c/papyrus/].<br />
<br />
Any issue should be reported using [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Papyrus Bugzilla].<br />
<br />
You may also contact the team using forums or mailing list:<br />
* [http://www.eclipse.org/forums/index.php?t=thread&frm_id=121 Papyrus forums]<br />
* [https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev Developer Mailing List] ([https://dev.eclipse.org/mhonarc/lists/mdt-papyrus.dev/ Mailing list Archive])<br />
<br />
<br />
[[Category:Modeling]]<br />
[[Category:Papyrus]]</div>Patrick.Tessier.cea.frhttps://wiki.eclipse.org/index.php?title=Papyrus&diff=443995Papyrus2021-09-22T09:25:01Z<p>Patrick.Tessier.cea.fr: /* Last news */</p>
<hr />
<div>=Overview=<br />
[https://eclipse.org/papyrus/ Papyrus] is an open source project to provide an integrated environment for editing [[MDT-UML2|UML]] and [https://www.eclipse.org/papyrus/components/sysml/ SysML] models. Specially, this project provides the glue around valuable UML and SysML diagram editors ([[GMF]]-based or not) and other MDE tools. It also offers support for UML and SysML profiling mechanisms. <br />
<br />
You can explore Papyrus's galaxy here [https://eclipse.org/papyrus/ https://eclipse.org/papyrus/].<br />
<br />
=Documentation=<br />
<br />
* Initial project description : [[MDT/Papyrus-Proposal | Papyrus component proposal]]<br />
* Guides<br />
** [https://help.eclipse.org/2020-09/index.jsp?nav=%2F73_0 2020/09 Papyrus User Guide]<br />
** [[Papyrus User Guide|User Guide]]<br />
** [[Papyrus/Papyrus Developer Guide | Developer Guide]]<br />
* Migration Guides<br />
** [[Papyrus/Migration Guide/Oxygen | Papyrus Oxygen (3.0) Migration Guide]]<br />
** [[Papyrus/Migration Guide/Neon | Papyrus Neon (2.0) Migration Guide]] — [[Media:Papyrus_Neon_Migration_Guide.pdf|as printable PDF]]<br />
<br />
<!--* Miscellaneous<br />
** [[General Architecture | General Architecture]]<br />
** [[Eclipse Papyrus FAQ|Eclipse Papyrus FAQ]]--><br />
<br />
=Papyrus Ecosystems=<br />
Informations about Papyrus relatives components are available [https://www.eclipse.org/papyrus/relatives.html here]<br />
<br />
* Papyrus4<br />
** [[Papyrus for Information Modeling | Papyrus4Information Modeling ]]<br />
** [[Papyrus for Education | Papyrus4Education]]<br />
* [https://www.eclipse.org/papyrus/relatives.html Papyrus Relatives]<br />
** [https://wiki.eclipse.org/Papyrus/UserGuide/ModelExecution Moka]<br />
<br />
=Road Map and Tasks=<br />
==Last news==<br />
<br />
* Integration problem<br />
Due to XWT integration issues, we were unable to post on time on the 2021-12 eclipse stream. However, we are going to carry out the RCP and update site in the coming weeks.<br />
<br />
== Current tasks==<br />
* We improve customization tools to be able validate customization models and to faster your customization work<br />
* We rework diagram code to reduce dead code<br />
* We add new 3 diagrams implantation (class, state machine, sequence) based on sirius technologies. To benefit of theses diagram, a module like relatives should be chosen.<br />
<br />
==About Releases (5.X)==<br />
* [[Papyrus/2020.12 Work Description | Incoming work for 2020.12]]<br />
* [[Papyrus/2021.03 Work Description | Incoming work for 2021.03]]<br />
* [[Papyrus/2021.06 Work Description | Incoming work for 2021.06]]<br />
<br />
==About Releases (4.X)==<br />
* [[Papyrus/2020.06 Work Description | Incoming work for 2020.06]]<br />
* [[Papyrus/2020.03 Work Description | Incoming work for 2020.03]]<br />
* [[Papyrus/2019.12 Work Description | Incoming work for 2019.12]]<br />
* [[Papyrus/2019.09 Work Description | Incoming work for 2019.09]]<br />
* [[Papyrus/2019.06 Work Description | Incoming work for 2019.06]]<br />
* [[Papyrus/2019.03 Work Description | Incoming work for 2019.03]]<br />
* [[Papyrus/2018.12 Work Description | Incoming work for 2018.12]]<br />
* [[Papyrus/2018.9 Work Description | Incoming work for 2018.9]]<br />
* [[Papyrus/Photon Work Description | Incoming work for Photon]]<br />
<br />
<br />
* [[Papyrus/Archives | Incoming works for previous releases]]<br />
<br />
=Team=<br />
The project committers are:<br />
* Ansgar Radermacher (CEA)<br />
* Camille Letavernier (EclipseSource) <br />
* Christian W. Damus (independant)<br />
* Florian Noyrit (CEA)<br />
* Jeremie Tatibouet (CEA)<br />
* Patrick Tessier (CEA)<br />
* Pauline Deville (CEA)<br />
* Quentin Le Menez (CEA)<br />
* Remi Schnekenburger (EclipseSource) <br />
* Shuai Li (CEA)<br />
* Vincent Lorenzo (CEA)<br />
<br />
<br/>Committers Emeritus:<br />
* Arnaud Cuccuru (CEA)<br />
* Arthur Daussy (ATOS)<br />
* Benoit Maggi (independant)<br />
* Cedric Dumoulin (LIFL)<br />
* Chokri Mraidha (CEA)<br />
* Juan Cadavid (CEA)<br />
* Mickael Adam (All4Tec)<br />
* Nicolas Fauvergue (independant)<br />
* Raphael Faudou (Samares)<br />
* Saadia Dhouib (CEA)<br />
* Sebastien Gerard (CEA – Project lead)<br />
* Tristan Faure (independant)<br />
<br />
=Contacts= <br />
<br />
You can browse the Papyrus git repositories at [https://git.eclipse.org/c/papyrus/ https://git.eclipse.org/c/papyrus/].<br />
<br />
Any issue should be reported using [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Papyrus Bugzilla].<br />
<br />
You may also contact the team using forums or mailing list:<br />
* [http://www.eclipse.org/forums/index.php?t=thread&frm_id=121 Papyrus forums]<br />
* [https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev Developer Mailing List] ([https://dev.eclipse.org/mhonarc/lists/mdt-papyrus.dev/ Mailing list Archive])<br />
<br />
<br />
[[Category:Modeling]]<br />
[[Category:Papyrus]]</div>Patrick.Tessier.cea.frhttps://wiki.eclipse.org/index.php?title=Papyrus&diff=443537Papyrus2021-06-24T08:37:50Z<p>Patrick.Tessier.cea.fr: /* Road Map and Tasks */</p>
<hr />
<div>=Overview=<br />
[https://eclipse.org/papyrus/ Papyrus] is an open source project to provide an integrated environment for editing [[MDT-UML2|UML]] and [https://www.eclipse.org/papyrus/components/sysml/ SysML] models. Specially, this project provides the glue around valuable UML and SysML diagram editors ([[GMF]]-based or not) and other MDE tools. It also offers support for UML and SysML profiling mechanisms. <br />
<br />
You can explore Papyrus's galaxy here [https://eclipse.org/papyrus/ https://eclipse.org/papyrus/].<br />
<br />
=Documentation=<br />
<br />
* Initial project description : [[MDT/Papyrus-Proposal | Papyrus component proposal]]<br />
* Guides<br />
** [https://help.eclipse.org/2020-09/index.jsp?nav=%2F73_0 2020/09 Papyrus User Guide]<br />
** [[Papyrus User Guide|User Guide]]<br />
** [[Papyrus/Papyrus Developer Guide | Developer Guide]]<br />
* Migration Guides<br />
** [[Papyrus/Migration Guide/Oxygen | Papyrus Oxygen (3.0) Migration Guide]]<br />
** [[Papyrus/Migration Guide/Neon | Papyrus Neon (2.0) Migration Guide]] — [[Media:Papyrus_Neon_Migration_Guide.pdf|as printable PDF]]<br />
<br />
<!--* Miscellaneous<br />
** [[General Architecture | General Architecture]]<br />
** [[Eclipse Papyrus FAQ|Eclipse Papyrus FAQ]]--><br />
<br />
=Papyrus Ecosystems=<br />
Informations about Papyrus relatives components are available [https://www.eclipse.org/papyrus/relatives.html here]<br />
<br />
* Papyrus4<br />
** [[Papyrus for Information Modeling | Papyrus4Information Modeling ]]<br />
** [[Papyrus for Education | Papyrus4Education]]<br />
* [https://www.eclipse.org/papyrus/relatives.html Papyrus Relatives]<br />
** [https://wiki.eclipse.org/Papyrus/UserGuide/ModelExecution Moka]<br />
<br />
=Road Map and Tasks=<br />
==Last news==<br />
<br />
* Integration problem<br />
Due to XWT integration issues, we were unable to post on time on the 2021-06 eclipse stream. However, we are going to carry out the RCP and update site in the coming weeks.<br />
<br />
We will be back on the train for 2021-09.<br />
<br />
* News about relatives<br />
** Designer is now compatible with Papyrus 5.X<br />
** Sysml 1.6 will be soon compatible<br />
** Moka have also been reworked to be compatible with work on re-exports and on Java11.<br />
== Current tasks==<br />
* We improve customization tools to be able validate customization models and to faster your customization work<br />
* We rework diagram code to reduce dead code<br />
* We add new 3 diagrams implantation (class, state machine, sequence) based on sirius technologies. To benefit of theses diagram, a module like relatives should be chosen.<br />
<br />
==About Releases (5.X)==<br />
* [[Papyrus/2020.12 Work Description | Incoming work for 2020.12]]<br />
* [[Papyrus/2021.03 Work Description | Incoming work for 2021.03]]<br />
* [[Papyrus/2021.06 Work Description | Incoming work for 2021.06]]<br />
<br />
==About Releases (4.X)==<br />
* [[Papyrus/2020.06 Work Description | Incoming work for 2020.06]]<br />
* [[Papyrus/2020.03 Work Description | Incoming work for 2020.03]]<br />
* [[Papyrus/2019.12 Work Description | Incoming work for 2019.12]]<br />
* [[Papyrus/2019.09 Work Description | Incoming work for 2019.09]]<br />
* [[Papyrus/2019.06 Work Description | Incoming work for 2019.06]]<br />
* [[Papyrus/2019.03 Work Description | Incoming work for 2019.03]]<br />
* [[Papyrus/2018.12 Work Description | Incoming work for 2018.12]]<br />
* [[Papyrus/2018.9 Work Description | Incoming work for 2018.9]]<br />
* [[Papyrus/Photon Work Description | Incoming work for Photon]]<br />
<br />
<br />
* [[Papyrus/Archives | Incoming works for previous releases]]<br />
<br />
=Team=<br />
The project committers are:<br />
* Ansgar Radermacher (CEA)<br />
* Camille Letavernier (EclipseSource) <br />
* Christian W. Damus (independant)<br />
* Florian Noyrit (CEA)<br />
* Jeremie Tatibouet (CEA)<br />
* Patrick Tessier (CEA)<br />
* Pauline Deville (CEA)<br />
* Quentin Le Menez (CEA)<br />
* Remi Schnekenburger (EclipseSource) <br />
* Shuai Li (CEA)<br />
* Vincent Lorenzo (CEA)<br />
<br />
<br/>Committers Emeritus:<br />
* Arnaud Cuccuru (CEA)<br />
* Arthur Daussy (ATOS)<br />
* Benoit Maggi (independant)<br />
* Cedric Dumoulin (LIFL)<br />
* Chokri Mraidha (CEA)<br />
* Juan Cadavid (CEA)<br />
* Mickael Adam (All4Tec)<br />
* Nicolas Fauvergue (independant)<br />
* Raphael Faudou (Samares)<br />
* Saadia Dhouib (CEA)<br />
* Sebastien Gerard (CEA – Project lead)<br />
* Tristan Faure (independant)<br />
<br />
=Contacts= <br />
<br />
You can browse the Papyrus git repositories at [https://git.eclipse.org/c/papyrus/ https://git.eclipse.org/c/papyrus/].<br />
<br />
Any issue should be reported using [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Papyrus Bugzilla].<br />
<br />
You may also contact the team using forums or mailing list:<br />
* [http://www.eclipse.org/forums/index.php?t=thread&frm_id=121 Papyrus forums]<br />
* [https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev Developer Mailing List] ([https://dev.eclipse.org/mhonarc/lists/mdt-papyrus.dev/ Mailing list Archive])<br />
<br />
<br />
[[Category:Modeling]]<br />
[[Category:Papyrus]]</div>Patrick.Tessier.cea.frhttps://wiki.eclipse.org/index.php?title=Papyrus/2021.06_Work_Description&diff=443536Papyrus/2021.06 Work Description2021-06-24T08:31:23Z<p>Patrick.Tessier.cea.fr: Created page with "Due to XWT integration issues, we were unable to post on time on the 2021-06 eclipse stream. However, we are going to carry out the RCP and update site in the coming weeks. W..."</p>
<hr />
<div>Due to XWT integration issues, we were unable to post on time on the 2021-06 eclipse stream. However, we are going to carry out the RCP and update site in the coming weeks.<br />
<br />
We will be back on the train for 2021-09.<br />
<br />
This version contains also improvement about customization tools</div>Patrick.Tessier.cea.frhttps://wiki.eclipse.org/index.php?title=Papyrus&diff=443535Papyrus2021-06-24T08:30:28Z<p>Patrick.Tessier.cea.fr: /* Last news */</p>
<hr />
<div>=Overview=<br />
[https://eclipse.org/papyrus/ Papyrus] is an open source project to provide an integrated environment for editing [[MDT-UML2|UML]] and [https://www.eclipse.org/papyrus/components/sysml/ SysML] models. Specially, this project provides the glue around valuable UML and SysML diagram editors ([[GMF]]-based or not) and other MDE tools. It also offers support for UML and SysML profiling mechanisms. <br />
<br />
You can explore Papyrus's galaxy here [https://eclipse.org/papyrus/ https://eclipse.org/papyrus/].<br />
<br />
=Documentation=<br />
<br />
* Initial project description : [[MDT/Papyrus-Proposal | Papyrus component proposal]]<br />
* Guides<br />
** [https://help.eclipse.org/2020-09/index.jsp?nav=%2F73_0 2020/09 Papyrus User Guide]<br />
** [[Papyrus User Guide|User Guide]]<br />
** [[Papyrus/Papyrus Developer Guide | Developer Guide]]<br />
* Migration Guides<br />
** [[Papyrus/Migration Guide/Oxygen | Papyrus Oxygen (3.0) Migration Guide]]<br />
** [[Papyrus/Migration Guide/Neon | Papyrus Neon (2.0) Migration Guide]] — [[Media:Papyrus_Neon_Migration_Guide.pdf|as printable PDF]]<br />
<br />
<!--* Miscellaneous<br />
** [[General Architecture | General Architecture]]<br />
** [[Eclipse Papyrus FAQ|Eclipse Papyrus FAQ]]--><br />
<br />
=Papyrus Ecosystems=<br />
Informations about Papyrus relatives components are available [https://www.eclipse.org/papyrus/relatives.html here]<br />
<br />
* Papyrus4<br />
** [[Papyrus for Information Modeling | Papyrus4Information Modeling ]]<br />
** [[Papyrus for Education | Papyrus4Education]]<br />
* [https://www.eclipse.org/papyrus/relatives.html Papyrus Relatives]<br />
** [https://wiki.eclipse.org/Papyrus/UserGuide/ModelExecution Moka]<br />
<br />
=Road Map and Tasks=<br />
==Last news==<br />
<br />
* Integration problem<br />
Due to XWT integration issues, we were unable to post on time on the 2021-06 eclipse stream. However, we are going to carry out the RCP and update site in the coming weeks.<br />
<br />
We will be back on the train for 2021-09.<br />
<br />
* News about relatives<br />
** Designer is now compatible with Papyrus 5.X<br />
** Sysml 1.6 will be soon compatible<br />
** Moka have also been reworked to be compatible with work on re-exports and on Java11.<br />
<br />
==About Releases (5.X)==<br />
* [[Papyrus/2020.12 Work Description | Incoming work for 2020.12]]<br />
* [[Papyrus/2021.03 Work Description | Incoming work for 2021.03]]<br />
* [[Papyrus/2021.06 Work Description | Incoming work for 2021.06]]<br />
<br />
==About Releases (4.X)==<br />
* [[Papyrus/2020.06 Work Description | Incoming work for 2020.06]]<br />
* [[Papyrus/2020.03 Work Description | Incoming work for 2020.03]]<br />
* [[Papyrus/2019.12 Work Description | Incoming work for 2019.12]]<br />
* [[Papyrus/2019.09 Work Description | Incoming work for 2019.09]]<br />
* [[Papyrus/2019.06 Work Description | Incoming work for 2019.06]]<br />
* [[Papyrus/2019.03 Work Description | Incoming work for 2019.03]]<br />
* [[Papyrus/2018.12 Work Description | Incoming work for 2018.12]]<br />
* [[Papyrus/2018.9 Work Description | Incoming work for 2018.9]]<br />
* [[Papyrus/Photon Work Description | Incoming work for Photon]]<br />
<br />
<br />
* [[Papyrus/Archives | Incoming works for previous releases]]<br />
<br />
=Team=<br />
The project committers are:<br />
* Ansgar Radermacher (CEA)<br />
* Camille Letavernier (EclipseSource) <br />
* Christian W. Damus (independant)<br />
* Florian Noyrit (CEA)<br />
* Jeremie Tatibouet (CEA)<br />
* Patrick Tessier (CEA)<br />
* Pauline Deville (CEA)<br />
* Quentin Le Menez (CEA)<br />
* Remi Schnekenburger (EclipseSource) <br />
* Shuai Li (CEA)<br />
* Vincent Lorenzo (CEA)<br />
<br />
<br/>Committers Emeritus:<br />
* Arnaud Cuccuru (CEA)<br />
* Arthur Daussy (ATOS)<br />
* Benoit Maggi (independant)<br />
* Cedric Dumoulin (LIFL)<br />
* Chokri Mraidha (CEA)<br />
* Juan Cadavid (CEA)<br />
* Mickael Adam (All4Tec)<br />
* Nicolas Fauvergue (independant)<br />
* Raphael Faudou (Samares)<br />
* Saadia Dhouib (CEA)<br />
* Sebastien Gerard (CEA – Project lead)<br />
* Tristan Faure (independant)<br />
<br />
=Contacts= <br />
<br />
You can browse the Papyrus git repositories at [https://git.eclipse.org/c/papyrus/ https://git.eclipse.org/c/papyrus/].<br />
<br />
Any issue should be reported using [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Papyrus Bugzilla].<br />
<br />
You may also contact the team using forums or mailing list:<br />
* [http://www.eclipse.org/forums/index.php?t=thread&frm_id=121 Papyrus forums]<br />
* [https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev Developer Mailing List] ([https://dev.eclipse.org/mhonarc/lists/mdt-papyrus.dev/ Mailing list Archive])<br />
<br />
<br />
[[Category:Modeling]]<br />
[[Category:Papyrus]]</div>Patrick.Tessier.cea.frhttps://wiki.eclipse.org/index.php?title=Papyrus&diff=443534Papyrus2021-06-24T08:28:32Z<p>Patrick.Tessier.cea.fr: /* Last news */</p>
<hr />
<div>=Overview=<br />
[https://eclipse.org/papyrus/ Papyrus] is an open source project to provide an integrated environment for editing [[MDT-UML2|UML]] and [https://www.eclipse.org/papyrus/components/sysml/ SysML] models. Specially, this project provides the glue around valuable UML and SysML diagram editors ([[GMF]]-based or not) and other MDE tools. It also offers support for UML and SysML profiling mechanisms. <br />
<br />
You can explore Papyrus's galaxy here [https://eclipse.org/papyrus/ https://eclipse.org/papyrus/].<br />
<br />
=Documentation=<br />
<br />
* Initial project description : [[MDT/Papyrus-Proposal | Papyrus component proposal]]<br />
* Guides<br />
** [https://help.eclipse.org/2020-09/index.jsp?nav=%2F73_0 2020/09 Papyrus User Guide]<br />
** [[Papyrus User Guide|User Guide]]<br />
** [[Papyrus/Papyrus Developer Guide | Developer Guide]]<br />
* Migration Guides<br />
** [[Papyrus/Migration Guide/Oxygen | Papyrus Oxygen (3.0) Migration Guide]]<br />
** [[Papyrus/Migration Guide/Neon | Papyrus Neon (2.0) Migration Guide]] — [[Media:Papyrus_Neon_Migration_Guide.pdf|as printable PDF]]<br />
<br />
<!--* Miscellaneous<br />
** [[General Architecture | General Architecture]]<br />
** [[Eclipse Papyrus FAQ|Eclipse Papyrus FAQ]]--><br />
<br />
=Papyrus Ecosystems=<br />
Informations about Papyrus relatives components are available [https://www.eclipse.org/papyrus/relatives.html here]<br />
<br />
* Papyrus4<br />
** [[Papyrus for Information Modeling | Papyrus4Information Modeling ]]<br />
** [[Papyrus for Education | Papyrus4Education]]<br />
* [https://www.eclipse.org/papyrus/relatives.html Papyrus Relatives]<br />
** [https://wiki.eclipse.org/Papyrus/UserGuide/ModelExecution Moka]<br />
<br />
=Road Map and Tasks=<br />
==Last news==<br />
<br />
Due to XWT integration issues, we were unable to post on time on the 2021-06 eclipse stream. However, we are going to carry out the RCP and update site in the coming weeks.<br />
<br />
We will be back on the train for 2021-09.<br />
<br />
Designer is now comptabible with Papyrus 5.X<br />
Sysml 1.6, Moka have also been reworked to be compatible with work on re-exports and on Java11.<br />
<br />
Papyrus Team<br />
<br />
==About Releases (5.X)==<br />
* [[Papyrus/2020.12 Work Description | Incoming work for 2020.12]]<br />
* [[Papyrus/2021.03 Work Description | Incoming work for 2021.03]]<br />
* [[Papyrus/2021.06 Work Description | Incoming work for 2021.06]]<br />
<br />
==About Releases (4.X)==<br />
* [[Papyrus/2020.06 Work Description | Incoming work for 2020.06]]<br />
* [[Papyrus/2020.03 Work Description | Incoming work for 2020.03]]<br />
* [[Papyrus/2019.12 Work Description | Incoming work for 2019.12]]<br />
* [[Papyrus/2019.09 Work Description | Incoming work for 2019.09]]<br />
* [[Papyrus/2019.06 Work Description | Incoming work for 2019.06]]<br />
* [[Papyrus/2019.03 Work Description | Incoming work for 2019.03]]<br />
* [[Papyrus/2018.12 Work Description | Incoming work for 2018.12]]<br />
* [[Papyrus/2018.9 Work Description | Incoming work for 2018.9]]<br />
* [[Papyrus/Photon Work Description | Incoming work for Photon]]<br />
<br />
<br />
* [[Papyrus/Archives | Incoming works for previous releases]]<br />
<br />
=Team=<br />
The project committers are:<br />
* Ansgar Radermacher (CEA)<br />
* Camille Letavernier (EclipseSource) <br />
* Christian W. Damus (independant)<br />
* Florian Noyrit (CEA)<br />
* Jeremie Tatibouet (CEA)<br />
* Patrick Tessier (CEA)<br />
* Pauline Deville (CEA)<br />
* Quentin Le Menez (CEA)<br />
* Remi Schnekenburger (EclipseSource) <br />
* Shuai Li (CEA)<br />
* Vincent Lorenzo (CEA)<br />
<br />
<br/>Committers Emeritus:<br />
* Arnaud Cuccuru (CEA)<br />
* Arthur Daussy (ATOS)<br />
* Benoit Maggi (independant)<br />
* Cedric Dumoulin (LIFL)<br />
* Chokri Mraidha (CEA)<br />
* Juan Cadavid (CEA)<br />
* Mickael Adam (All4Tec)<br />
* Nicolas Fauvergue (independant)<br />
* Raphael Faudou (Samares)<br />
* Saadia Dhouib (CEA)<br />
* Sebastien Gerard (CEA – Project lead)<br />
* Tristan Faure (independant)<br />
<br />
=Contacts= <br />
<br />
You can browse the Papyrus git repositories at [https://git.eclipse.org/c/papyrus/ https://git.eclipse.org/c/papyrus/].<br />
<br />
Any issue should be reported using [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Papyrus Bugzilla].<br />
<br />
You may also contact the team using forums or mailing list:<br />
* [http://www.eclipse.org/forums/index.php?t=thread&frm_id=121 Papyrus forums]<br />
* [https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev Developer Mailing List] ([https://dev.eclipse.org/mhonarc/lists/mdt-papyrus.dev/ Mailing list Archive])<br />
<br />
<br />
[[Category:Modeling]]<br />
[[Category:Papyrus]]</div>Patrick.Tessier.cea.frhttps://wiki.eclipse.org/index.php?title=Papyrus/2020.12_Work_Description&diff=443533Papyrus/2020.12 Work Description2021-06-24T08:27:13Z<p>Patrick.Tessier.cea.fr: </p>
<hr />
<div>All the work realized by CEA LIST is sponsored by CEA LIST. All bugs, or feature may be found in the tracker[https://projects.eclipse.org/projects/modeling.mdt.papyrus/releases/5.0.0/bugs] .<br />
<br />
Papyrus 5.0 contains new features:<br />
<br />
It is now possible to associate a set of customization of the model explorer to the architecture framework.<br />
<br />
A huge job has been done to remove all re-exports on dependencies.<br />
<br />
Now papyrus 5.0 compiles on Java11.</div>Patrick.Tessier.cea.frhttps://wiki.eclipse.org/index.php?title=Papyrus/2021.03_Work_Description&diff=443532Papyrus/2021.03 Work Description2021-06-24T08:26:29Z<p>Patrick.Tessier.cea.fr: </p>
<hr />
<div>All the work realized by CEA LIST is sponsored by CEA LIST.<br />
All bugs, or feature may be found in the tracker [https://projects.eclipse.org/projects/modeling.mdt.papyrus/releases/5.1.0/bugs].<br />
<br />
We mainly worked on support improving papyrus customization tools.</div>Patrick.Tessier.cea.frhttps://wiki.eclipse.org/index.php?title=Papyrus/2021.03_Work_Description&diff=443531Papyrus/2021.03 Work Description2021-06-24T08:24:58Z<p>Patrick.Tessier.cea.fr: Created page with "All the work realized by CEA LIST is sponsored by CEA LIST. All bugs, or feature may be found in the tracker [https://projects.eclipse.org/projects/modeling.mdt.papyrus/releas..."</p>
<hr />
<div>All the work realized by CEA LIST is sponsored by CEA LIST.<br />
All bugs, or feature may be found in the tracker [https://projects.eclipse.org/projects/modeling.mdt.papyrus/releases/5.1.0/bugs].<br />
<br />
Papyrus 4.8 contains bug fixes<br />
<br />
===Table editor:===<br />
*management of empty row<br />
*performance improvement<br />
===State diagrams:===<br />
*fix creation of regions<br />
===Activity diagrams===<br />
*improve reactivity during creation of a link betwen nodes</div>Patrick.Tessier.cea.frhttps://wiki.eclipse.org/index.php?title=Papyrus&diff=443530Papyrus2021-06-24T08:24:12Z<p>Patrick.Tessier.cea.fr: /* Documentation */</p>
<hr />
<div>=Overview=<br />
[https://eclipse.org/papyrus/ Papyrus] is an open source project to provide an integrated environment for editing [[MDT-UML2|UML]] and [https://www.eclipse.org/papyrus/components/sysml/ SysML] models. Specially, this project provides the glue around valuable UML and SysML diagram editors ([[GMF]]-based or not) and other MDE tools. It also offers support for UML and SysML profiling mechanisms. <br />
<br />
You can explore Papyrus's galaxy here [https://eclipse.org/papyrus/ https://eclipse.org/papyrus/].<br />
<br />
=Documentation=<br />
<br />
* Initial project description : [[MDT/Papyrus-Proposal | Papyrus component proposal]]<br />
* Guides<br />
** [https://help.eclipse.org/2020-09/index.jsp?nav=%2F73_0 2020/09 Papyrus User Guide]<br />
** [[Papyrus User Guide|User Guide]]<br />
** [[Papyrus/Papyrus Developer Guide | Developer Guide]]<br />
* Migration Guides<br />
** [[Papyrus/Migration Guide/Oxygen | Papyrus Oxygen (3.0) Migration Guide]]<br />
** [[Papyrus/Migration Guide/Neon | Papyrus Neon (2.0) Migration Guide]] — [[Media:Papyrus_Neon_Migration_Guide.pdf|as printable PDF]]<br />
<br />
<!--* Miscellaneous<br />
** [[General Architecture | General Architecture]]<br />
** [[Eclipse Papyrus FAQ|Eclipse Papyrus FAQ]]--><br />
<br />
=Papyrus Ecosystems=<br />
Informations about Papyrus relatives components are available [https://www.eclipse.org/papyrus/relatives.html here]<br />
<br />
* Papyrus4<br />
** [[Papyrus for Information Modeling | Papyrus4Information Modeling ]]<br />
** [[Papyrus for Education | Papyrus4Education]]<br />
* [https://www.eclipse.org/papyrus/relatives.html Papyrus Relatives]<br />
** [https://wiki.eclipse.org/Papyrus/UserGuide/ModelExecution Moka]<br />
<br />
=Road Map and Tasks=<br />
==Last news==<br />
<br />
Due to XWT integration issues, we were unable to post on time on the 2021-06 eclipse stream. However, we are going to carry out the RCP and update site in the coming weeks.<br />
<br />
We will be back on the train for 2021-09.<br />
<br />
Papyrus Team<br />
<br />
==About Releases (5.X)==<br />
* [[Papyrus/2020.12 Work Description | Incoming work for 2020.12]]<br />
* [[Papyrus/2021.03 Work Description | Incoming work for 2021.03]]<br />
* [[Papyrus/2021.06 Work Description | Incoming work for 2021.06]]<br />
<br />
==About Releases (4.X)==<br />
* [[Papyrus/2020.06 Work Description | Incoming work for 2020.06]]<br />
* [[Papyrus/2020.03 Work Description | Incoming work for 2020.03]]<br />
* [[Papyrus/2019.12 Work Description | Incoming work for 2019.12]]<br />
* [[Papyrus/2019.09 Work Description | Incoming work for 2019.09]]<br />
* [[Papyrus/2019.06 Work Description | Incoming work for 2019.06]]<br />
* [[Papyrus/2019.03 Work Description | Incoming work for 2019.03]]<br />
* [[Papyrus/2018.12 Work Description | Incoming work for 2018.12]]<br />
* [[Papyrus/2018.9 Work Description | Incoming work for 2018.9]]<br />
* [[Papyrus/Photon Work Description | Incoming work for Photon]]<br />
<br />
<br />
* [[Papyrus/Archives | Incoming works for previous releases]]<br />
<br />
=Team=<br />
The project committers are:<br />
* Ansgar Radermacher (CEA)<br />
* Camille Letavernier (EclipseSource) <br />
* Christian W. Damus (independant)<br />
* Florian Noyrit (CEA)<br />
* Jeremie Tatibouet (CEA)<br />
* Patrick Tessier (CEA)<br />
* Pauline Deville (CEA)<br />
* Quentin Le Menez (CEA)<br />
* Remi Schnekenburger (EclipseSource) <br />
* Shuai Li (CEA)<br />
* Vincent Lorenzo (CEA)<br />
<br />
<br/>Committers Emeritus:<br />
* Arnaud Cuccuru (CEA)<br />
* Arthur Daussy (ATOS)<br />
* Benoit Maggi (independant)<br />
* Cedric Dumoulin (LIFL)<br />
* Chokri Mraidha (CEA)<br />
* Juan Cadavid (CEA)<br />
* Mickael Adam (All4Tec)<br />
* Nicolas Fauvergue (independant)<br />
* Raphael Faudou (Samares)<br />
* Saadia Dhouib (CEA)<br />
* Sebastien Gerard (CEA – Project lead)<br />
* Tristan Faure (independant)<br />
<br />
=Contacts= <br />
<br />
You can browse the Papyrus git repositories at [https://git.eclipse.org/c/papyrus/ https://git.eclipse.org/c/papyrus/].<br />
<br />
Any issue should be reported using [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Papyrus Bugzilla].<br />
<br />
You may also contact the team using forums or mailing list:<br />
* [http://www.eclipse.org/forums/index.php?t=thread&frm_id=121 Papyrus forums]<br />
* [https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev Developer Mailing List] ([https://dev.eclipse.org/mhonarc/lists/mdt-papyrus.dev/ Mailing list Archive])<br />
<br />
<br />
[[Category:Modeling]]<br />
[[Category:Papyrus]]</div>Patrick.Tessier.cea.frhttps://wiki.eclipse.org/index.php?title=Papyrus&diff=443529Papyrus2021-06-24T08:22:42Z<p>Patrick.Tessier.cea.fr: /* Next Major release :2020-12 */</p>
<hr />
<div>=Overview=<br />
[https://eclipse.org/papyrus/ Papyrus] is an open source project to provide an integrated environment for editing [[MDT-UML2|UML]] and [https://www.eclipse.org/papyrus/components/sysml/ SysML] models. Specially, this project provides the glue around valuable UML and SysML diagram editors ([[GMF]]-based or not) and other MDE tools. It also offers support for UML and SysML profiling mechanisms. <br />
<br />
You can explore Papyrus's galaxy here [https://eclipse.org/papyrus/ https://eclipse.org/papyrus/].<br />
<br />
=Documentation=<br />
<br />
* Initial project description : [[MDT/Papyrus-Proposal | Papyrus component proposal]]<br />
* Guides<br />
** [https://help.eclipse.org/2020-09/index.jsp?nav=%2F73_0 2020/09 Papyrus User Guide]<br />
** [[Papyrus User Guide|User Guide]]<br />
** [[Papyrus/Papyrus Developer Guide | Developer Guide]]<br />
* Migration Guides<br />
** Migration guide 4.x to 5.x is coming soon <br />
** [[Papyrus/Migration Guide/Oxygen | Papyrus Oxygen (3.0) Migration Guide]]<br />
** [[Papyrus/Migration Guide/Neon | Papyrus Neon (2.0) Migration Guide]] — [[Media:Papyrus_Neon_Migration_Guide.pdf|as printable PDF]]<br />
<br />
<!--* Miscellaneous<br />
** [[General Architecture | General Architecture]]<br />
** [[Eclipse Papyrus FAQ|Eclipse Papyrus FAQ]]--><br />
<br />
=Papyrus Ecosystems=<br />
Informations about Papyrus relatives components are available [https://www.eclipse.org/papyrus/relatives.html here]<br />
<br />
* Papyrus4<br />
** [[Papyrus for Information Modeling | Papyrus4Information Modeling ]]<br />
** [[Papyrus for Education | Papyrus4Education]]<br />
* [https://www.eclipse.org/papyrus/relatives.html Papyrus Relatives]<br />
** [https://wiki.eclipse.org/Papyrus/UserGuide/ModelExecution Moka]<br />
<br />
=Road Map and Tasks=<br />
==Last news==<br />
<br />
Due to XWT integration issues, we were unable to post on time on the 2021-06 eclipse stream. However, we are going to carry out the RCP and update site in the coming weeks.<br />
<br />
We will be back on the train for 2021-09.<br />
<br />
Papyrus Team<br />
<br />
==About Releases (5.X)==<br />
* [[Papyrus/2020.12 Work Description | Incoming work for 2020.12]]<br />
* [[Papyrus/2021.03 Work Description | Incoming work for 2021.03]]<br />
* [[Papyrus/2021.06 Work Description | Incoming work for 2021.06]]<br />
<br />
==About Releases (4.X)==<br />
* [[Papyrus/2020.06 Work Description | Incoming work for 2020.06]]<br />
* [[Papyrus/2020.03 Work Description | Incoming work for 2020.03]]<br />
* [[Papyrus/2019.12 Work Description | Incoming work for 2019.12]]<br />
* [[Papyrus/2019.09 Work Description | Incoming work for 2019.09]]<br />
* [[Papyrus/2019.06 Work Description | Incoming work for 2019.06]]<br />
* [[Papyrus/2019.03 Work Description | Incoming work for 2019.03]]<br />
* [[Papyrus/2018.12 Work Description | Incoming work for 2018.12]]<br />
* [[Papyrus/2018.9 Work Description | Incoming work for 2018.9]]<br />
* [[Papyrus/Photon Work Description | Incoming work for Photon]]<br />
<br />
<br />
* [[Papyrus/Archives | Incoming works for previous releases]]<br />
<br />
=Team=<br />
The project committers are:<br />
* Ansgar Radermacher (CEA)<br />
* Camille Letavernier (EclipseSource) <br />
* Christian W. Damus (independant)<br />
* Florian Noyrit (CEA)<br />
* Jeremie Tatibouet (CEA)<br />
* Patrick Tessier (CEA)<br />
* Pauline Deville (CEA)<br />
* Quentin Le Menez (CEA)<br />
* Remi Schnekenburger (EclipseSource) <br />
* Shuai Li (CEA)<br />
* Vincent Lorenzo (CEA)<br />
<br />
<br/>Committers Emeritus:<br />
* Arnaud Cuccuru (CEA)<br />
* Arthur Daussy (ATOS)<br />
* Benoit Maggi (independant)<br />
* Cedric Dumoulin (LIFL)<br />
* Chokri Mraidha (CEA)<br />
* Juan Cadavid (CEA)<br />
* Mickael Adam (All4Tec)<br />
* Nicolas Fauvergue (independant)<br />
* Raphael Faudou (Samares)<br />
* Saadia Dhouib (CEA)<br />
* Sebastien Gerard (CEA – Project lead)<br />
* Tristan Faure (independant)<br />
<br />
=Contacts= <br />
<br />
You can browse the Papyrus git repositories at [https://git.eclipse.org/c/papyrus/ https://git.eclipse.org/c/papyrus/].<br />
<br />
Any issue should be reported using [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Papyrus Bugzilla].<br />
<br />
You may also contact the team using forums or mailing list:<br />
* [http://www.eclipse.org/forums/index.php?t=thread&frm_id=121 Papyrus forums]<br />
* [https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev Developer Mailing List] ([https://dev.eclipse.org/mhonarc/lists/mdt-papyrus.dev/ Mailing list Archive])<br />
<br />
<br />
[[Category:Modeling]]<br />
[[Category:Papyrus]]</div>Patrick.Tessier.cea.frhttps://wiki.eclipse.org/index.php?title=Papyrus&diff=443528Papyrus2021-06-24T08:21:04Z<p>Patrick.Tessier.cea.fr: /* About Releases (5.X) */</p>
<hr />
<div>=Overview=<br />
[https://eclipse.org/papyrus/ Papyrus] is an open source project to provide an integrated environment for editing [[MDT-UML2|UML]] and [https://www.eclipse.org/papyrus/components/sysml/ SysML] models. Specially, this project provides the glue around valuable UML and SysML diagram editors ([[GMF]]-based or not) and other MDE tools. It also offers support for UML and SysML profiling mechanisms. <br />
<br />
You can explore Papyrus's galaxy here [https://eclipse.org/papyrus/ https://eclipse.org/papyrus/].<br />
<br />
=Documentation=<br />
<br />
* Initial project description : [[MDT/Papyrus-Proposal | Papyrus component proposal]]<br />
* Guides<br />
** [https://help.eclipse.org/2020-09/index.jsp?nav=%2F73_0 2020/09 Papyrus User Guide]<br />
** [[Papyrus User Guide|User Guide]]<br />
** [[Papyrus/Papyrus Developer Guide | Developer Guide]]<br />
* Migration Guides<br />
** Migration guide 4.x to 5.x is coming soon <br />
** [[Papyrus/Migration Guide/Oxygen | Papyrus Oxygen (3.0) Migration Guide]]<br />
** [[Papyrus/Migration Guide/Neon | Papyrus Neon (2.0) Migration Guide]] — [[Media:Papyrus_Neon_Migration_Guide.pdf|as printable PDF]]<br />
<br />
<!--* Miscellaneous<br />
** [[General Architecture | General Architecture]]<br />
** [[Eclipse Papyrus FAQ|Eclipse Papyrus FAQ]]--><br />
<br />
=Papyrus Ecosystems=<br />
Informations about Papyrus relatives components are available [https://www.eclipse.org/papyrus/relatives.html here]<br />
<br />
* Papyrus4<br />
** [[Papyrus for Information Modeling | Papyrus4Information Modeling ]]<br />
** [[Papyrus for Education | Papyrus4Education]]<br />
* [https://www.eclipse.org/papyrus/relatives.html Papyrus Relatives]<br />
** [https://wiki.eclipse.org/Papyrus/UserGuide/ModelExecution Moka]<br />
<br />
=Road Map and Tasks=<br />
==Next Major release :2020-12==<br />
<br />
We will now begin to work on the next major release of papyrus (5.0.0) in order to allow us some API changes and other corrections. This version will be available in time to integrate the '''2020-12 release train'''.<br />
<br />
Because we need to focus on this goal, there is no release planned for the 2020-09 train. <br />
<br />
The 5.0.0 release will contain, for example, the refactoring of some dependencies such as removing the reexports wherever possible and removing deprecated APIs lingering for far too long in the code base.<br />
<br />
We will inform you about any work undertaken on the wiki page [[Papyrus/2020.12 Work Description | Incoming work for 2020-12]].<br />
<br />
==About Releases (5.X)==<br />
* [[Papyrus/2020.12 Work Description | Incoming work for 2020.12]]<br />
* [[Papyrus/2021.03 Work Description | Incoming work for 2021.03]]<br />
* [[Papyrus/2021.06 Work Description | Incoming work for 2021.06]]<br />
<br />
==About Releases (4.X)==<br />
* [[Papyrus/2020.06 Work Description | Incoming work for 2020.06]]<br />
* [[Papyrus/2020.03 Work Description | Incoming work for 2020.03]]<br />
* [[Papyrus/2019.12 Work Description | Incoming work for 2019.12]]<br />
* [[Papyrus/2019.09 Work Description | Incoming work for 2019.09]]<br />
* [[Papyrus/2019.06 Work Description | Incoming work for 2019.06]]<br />
* [[Papyrus/2019.03 Work Description | Incoming work for 2019.03]]<br />
* [[Papyrus/2018.12 Work Description | Incoming work for 2018.12]]<br />
* [[Papyrus/2018.9 Work Description | Incoming work for 2018.9]]<br />
* [[Papyrus/Photon Work Description | Incoming work for Photon]]<br />
<br />
<br />
* [[Papyrus/Archives | Incoming works for previous releases]]<br />
<br />
=Team=<br />
The project committers are:<br />
* Ansgar Radermacher (CEA)<br />
* Camille Letavernier (EclipseSource) <br />
* Christian W. Damus (independant)<br />
* Florian Noyrit (CEA)<br />
* Jeremie Tatibouet (CEA)<br />
* Patrick Tessier (CEA)<br />
* Pauline Deville (CEA)<br />
* Quentin Le Menez (CEA)<br />
* Remi Schnekenburger (EclipseSource) <br />
* Shuai Li (CEA)<br />
* Vincent Lorenzo (CEA)<br />
<br />
<br/>Committers Emeritus:<br />
* Arnaud Cuccuru (CEA)<br />
* Arthur Daussy (ATOS)<br />
* Benoit Maggi (independant)<br />
* Cedric Dumoulin (LIFL)<br />
* Chokri Mraidha (CEA)<br />
* Juan Cadavid (CEA)<br />
* Mickael Adam (All4Tec)<br />
* Nicolas Fauvergue (independant)<br />
* Raphael Faudou (Samares)<br />
* Saadia Dhouib (CEA)<br />
* Sebastien Gerard (CEA – Project lead)<br />
* Tristan Faure (independant)<br />
<br />
=Contacts= <br />
<br />
You can browse the Papyrus git repositories at [https://git.eclipse.org/c/papyrus/ https://git.eclipse.org/c/papyrus/].<br />
<br />
Any issue should be reported using [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Papyrus Bugzilla].<br />
<br />
You may also contact the team using forums or mailing list:<br />
* [http://www.eclipse.org/forums/index.php?t=thread&frm_id=121 Papyrus forums]<br />
* [https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev Developer Mailing List] ([https://dev.eclipse.org/mhonarc/lists/mdt-papyrus.dev/ Mailing list Archive])<br />
<br />
<br />
[[Category:Modeling]]<br />
[[Category:Papyrus]]</div>Patrick.Tessier.cea.frhttps://wiki.eclipse.org/index.php?title=Papyrus/Papyrus_Developer_Guide/How_to_Contribute_to_Papyrus_with_Gerrit&diff=442734Papyrus/Papyrus Developer Guide/How to Contribute to Papyrus with Gerrit2021-03-24T13:24:56Z<p>Patrick.Tessier.cea.fr: /* Sign in the eclipse development chart */</p>
<hr />
<div>Using Gerrit, you can contribute to the Papryrus project, even if you aren't a committer. <br />
If you have not cloned the repository yet please follow the tutorial available [[Papyrus Developer Guide/Papyrus Git Tutorial | here]].<br />
<br />
<br />
<br />
=== Sign in the eclipse development chart ===<br />
<br />
*Create an Eclipse Bugzilla account : https://dev.eclipse.org/site_login/createaccount.php<br />
This step is your average account creation, and it will require you to visit a mail sent URL to validate the account.<br />
*Sign the ECA : https://www.eclipse.org/legal/ECA.php<br />
This can be done ( by visitiing the following link: https://projects.eclipse.org/user/login/sso ) once logged in by clicking on Contributor License Agreement and following all the instruction on this same page.<br />
*Activate your Gerrit account : https://git.eclipse.org/r/<br />
The id and password , just as your sign-in information on the eclipse website, are the mail address you used to create the eclipse account and the associated password, no need to create a new one.<br />
*And Add your ssh key, if you have one, to your gerrit account by going into your settings and then <b>SSH Public Keys>Add Key</b> and paste the newly generated public key. It should look like: <b>[algorithm] [key] [comment]</b>, as shown here the first one is of the form: <b>ssh-rsa xxxxxxxxx Generated</b><br />
<br />
[[File:EGit_ssh2.png|1000px]]<br />
<br />
<br /><br /><br />
<br />
=== Configure push for Gerrit ===<br />
<br />
Because you're not an official Papyrus commiter, you can't just commit your code on the papyrus git repository; you have to submit your contribution via the commit refs/for/master branch. <br />
<br />
<br />
==== Via EGit ====<br />
You can configure EGit for push on that particular branch:<br />
<br />
* On the Git Repositories view, open ''Remotes''<br />
* Add a new Remote by right clicking on ''Remotes'', then choose ''Create Remote...'', and choose a new name (for example Gerrit) <br />
N.B. : you can also choose to modify the origin remote.<br />
* Configure Gerrit for this remote by right clicking on it, and Gerrit Configuration<br />
<br />
You now have to configure the repository URI :<br />
* Choose your preferred protocole (http, https, ssh)<br />
* Enter the papyrus URI : <br />
** via ssh : '''ssh://[committer_id]@git.eclipse.org:29418/papyrus/org.eclipse.papyrus''', where [commiter_id] is your Gerrit id.<br />
** via https : '''https://[committer_id]@git.eclipse.org/r/papyrus/org.eclipse.papyrus'''<br />
<br />
[[File:EGit_PushConfigurations.png | 800px]]<br />
<br />
<br /><br /><br />
<br />
* The above push configurations already contain your Gerrit id in the adress, and therefore the Gerrit id field will be updated automatically in the configuration window.<br />
* You may want to enter you password so that you won't have to type it on each push.<br />
<br />
If you're experiencing problems, please verify that you're pushing on refs/for/master (Or refs/drafts/master for hidden review)<br />
<br />
<br /><br />
<br />
==== Via command line ====<br />
git remote add sshGerrit ssh://[[committer_id]]@git.eclipse.org:29418/papyrus/org.eclipse.papyrus<br />
<br />
Before commit somethings for papyrus do not forget to configure your git with<br />
<br />
core.autocrlf = input<br />
<br />
=== How to commit using EGit ===<br />
<br />
A good way to do this is to open the Git perspective inside your eclipse window as it will have all the necessary views to achieve what you want to do in this case.<br />
The first step is to verify that your local branches have a remote assigned and that it is the remote you want to push on, as the mechanism of commit and push of egit will select this one by default. This can be done easily by clicking on the branch in your Git repository interface and selecting the "Configure Branch" option.<br />
<br />
[[File:EGit_Branch_Configuration0.png | 600px]]<br />
<br />
Or by editing the <b>Preferences>Team>Git>Configuration</b> "Repository Settings" and defining which default remote your branch will be attached to.<br />
<br />
[[File:EGit_Branch_Configuration2.png | 1000px]]<br />
<br />
<br /><br /><br />
<br />
Once this is done you will have to create, or amend, the commit by going to the "Git Staging" tab. there you will have all the changes detected by EGit (it might be a little messy and full of files you didn't even touch, as is the case in this image, but don't pay it attention as your changes will be there as well) and drag the wanted files from <b> Unstaged Changes </b> to <b> Staged Changes </b>. then edit the commit message:<br />
* The first line of your commit comment should be the bugzilla task number and its name; example : Bug 12345 - The name of the bug you fixed.<br />
* Then should be the fixes you provided<br />
* If it is an amend of a precedent commit be sure to add the Change-Id provided by gerrit (upper left corner of the gerrit page) and separate the Change-Id from the rest of the meassage with a blank line<br />
* You will then have to sign-off your commit <br />
<br />
[[File:EGit_Staging1.png | 1000px]]<br />
<br />
[[File:EGit_Staging2.png | 1000px]]<br />
<br />
If you only need to amend a commit EGit provides a fast way to edit the message with the "amend previous commit", "add signed off by" and "add Change Id" buttons. You can then pr<br />
<br />
[[File:EGit_Staging0.png | 1000px]]<br />
<br />
<br /><br /><br />
<br />
The first commit on a Bug won't have a change-id as this will be created when the commit is pushed and accepted by Gerrit. The change-id can be retrieved by visiting the pushed commit on Gerrit.<br />
With EGit the "amend previous commit" button should fill the new commit's message with the previous fields. It is important to know that the Change-Id must be separated from the commit message by a blank line, so that it will be identified from the rest of the message and your push to gerrit will update the existing one.<br />
<br />
==== Once the commit is submitted ====<br />
<br />
Once all this is done, don't forget to link the gerrit page inside a comment in the related Bugzilla page. This little update will make things easier for the users and even serve you as a reminder to close or update the Bugzilla status ! <br />
<br />
Gerrit & Bugzilla are now synchronized. A reference from Bugzilla to the Gerrit contribution is now automatically added as soon as the contribution is proposed, and another comment is added when the contribution is accepted (merged). Note that this synchronization can only happen if the Contribution contains the Bug ID in the commit message (‘<b>Bug 123456</b>: ....’). Also note that by default, Mylyn/Bugzilla only writes the bug number (Without the ‘Bug’ prefix), which doesn’t trigger the automatic synchronization.<br />
<br />
<br /><br />
<br />
=== How to commit using commands ===<br />
<br />
The editor used in this section is Cygwin ( https://www.cygwin.com/ ), to which we added the specific git packages: git-completion, gui, svn and fast version control system. To install them choose a site, such as mirrors.kernel.org<br />
To make the display more comfortable and easier to read, it is preferable to run the following command: <b> git config --global color.ui true </b>, if it is not already enabled, so that you will have access to all the nice colors. Also, if you are allergic to VI, try installing another editor, like nano.<br />
<br />
<br /><br />
==== Install the commit-hook in your local repository ====<br />
<br />
This hook will automaticaly insert ''Gerrit Change-Id'' in your commit message<br />
scp -p -P 29418 username@git.eclipse.org:hooks/commit-msg .git/hooks/<br />
see also [[EGit/Contributor_Guide#Install_the_commit-msg_hook_in_your_repository|Install the commit-msg hook in your repository]]<br />
<br />
<br />
==== First push - How to commit and push ====<br />
<br />
[[File:first_Commit.png | 1000px]]<br />
<br />
Having created an empty file (using the touch command) inside the git repository, git sees it as a modification and therefore the <b> git status </b> command shows the file as untracked. <br />
We add it to the index of the next commit using <b> git add [file name] </b> and as you can see by the second <b> git status </b> the file testGerrit.txt is in the "Changes to be committed".<br />
The next step is to create the commit itself. For this purpose we run the <b> git commit -m "[your commit message]" --signoff </b> command. This command decompose itself in 3:<br />
* The actual order of commit, by using the commit keyword<br />
* The message we want to asociate with the commit, by using -m an entering the commit message between comas<br />
* The addition of the signature without which your commit will be refused, by adding --signoff (or just -s). This signature is comprised of your previously defined user name and user email.<br />
<br />
Before pushing on gerrit it is preferable to update your local branch from the remote as that should prevent merge conflicts if your change is accepted and merged. <br />
* To do this we used the <b> git fetch </b> ( short for: git fetch [name of the git remote], and in this example the remote of the repository is named "origin" ) that will import all the changes (commits) that happened since the last update of the branch or, if no update were done, since the creation of the branch.<br />
* And <b> git rebase </b> ( short for: git rebase [name of the remote branch], which in this case is "origin/master" ) that will detach all the work done on the local branch, patch the local branch with the changes that happened on the remote branch and replay the work on top of them, effectively giving you an updated branch and clean base to push your new commit.<br />
<br />
[[File:fetch&rebase.png | 600px]]<br />
<br />
<br /><br /><br />
<br />
Then, we push the commit onto Gerrit. It will signal you if the build incorporating your changes has failed and allow your code to be reviewed before being merged. Instead of pushing to the actual branch, your local is based on, Gerrit uses "magic branches", effectively virtual branches, for the purpose of reviewing the code and pushing it, or not depending on the review, on the actual git remote. Those are identified with the "refs/for/[remote]" tag.<br />
<br />
[[File:Gerrit_Magic_Branches.png | 600px]]<br />
<br />
[[File:first_Push_Https.png | 1000px]]<br />
<br />
<br /><br /><br />
<br />
You will be able to see your contribution by opening Gerrit's web interface ( https://git.eclipse.org/r ). Filters can be applied in the search fieldbox. Useful ones in this case are:<br />
* status:open, that will only show the opened and not yet reviewed commits<br />
* project:papyrus/org.eclipse.papyrus, that will only show commit related to the papyrus project<br />
<br />
And this is what your commit details will look like:<br />
<br />
[[File:first_Push_Result.png | 1000px]]<br />
<br />
<br /><br />
<br />
==== Second push - What not to do, or not too often ====<br />
<br />
Please keep in mind that, for the following steps ("second push" and "third push"), we are in the Gerrit situation where the contribution has not yet been merged. Amended commits are actually entirely new commits, and the previous commit is removed from the project history. If you amend a commit that other developers have based their work on it will look like the basis of their work has vanished from the project history and that is a tricky situation to recover from. <br />
<br />
Now lets say that you want to add modifications to the project you are working on. In this case we just create a new file "testGerritMod.txt". As a newly created file, a "git status" tells us that it is added to the untracked list, that is the not yet committed files. We add the new file to the index and create a new commit as usual and adding the Change-Id to our message in order to signify gerrit that it is a modification of our first commit. As a reminder, remember to put an empty line between the commit message and the footer containing the Change-Id.<br />
<br />
[[File:second_Commit.png | 1000px]]<br />
<br />
<br /><br /><br />
<br />
But the problem is that we did not amend the first commit but created a new and different commit altogether without deleting the first one. Therefore we try to have two commits with the same Change-Id and that is just not possible. The push order gets rejected. Time for a squash, that is a rebase -i, of our two commits: <b> git rebase -i HEAD~2 </b> which means that we get the last two commits (~2) done from our local branch (HEAD).<br />
We then get an editor in which we choose how to fuse the commits together (image pending) and, once this is done, another that allows us to edit and choose which commit message to use.<br />
<br />
[[File:squash_For_Second_Push.png | 1000px]]<br />
<br />
[[File:squash_Commits_Message1.png | 1000px]]<br />
<br />
[[File:squash_Commits_Message2.png | 1000px]]<br />
<br />
<br /><br /><br />
<br />
As we can see the updated gerrit contribution contains the new file and the updated commit message.<br />
<br />
[[File:second_Push_Result.png | 1000px]]<br />
<br />
<br /><br />
<br />
==== Third push - How to do it correctly ====<br />
<br />
To amend a commit properly you just have to run the <b> git commit --amend </b> that will allow you to amend the last commit done on this branch. In this case we create a new file to our test, add it to the index and then run the command. The new file is added to the commit and a message editor is opened to allow us to modify the commit message if need be. After making sure that our branch is still up to date, we push the new modification on gerrit (this time by ssh just to show that you can manipulate both together).<br />
<br />
[[File:third_Commit_Amend.png | 1000px]]<br />
<br />
[[File:third_Commit_Message_Amend1.png | 1000px]]<br />
<br />
[[File:third_Commit_Message_Amend2.png | 1000px]]<br />
<br />
<br /><br /><br />
<br />
Now that all is up to speed we can push the new modifications.<br />
<br />
[[File:third_Push_SSH.png | 1000px]]<br />
<br />
<br /><br /><br />
<br />
And the resulting modifications on the Gerrit page.<br />
<br />
[[File:third_Push_Result.png | 1000px]]<br />
<br />
<br /><br /><br />
<br />
=== Useful Tips ===<br />
<br />
==== Git Commands ====<br />
<br />
Here is a list a commands you may find useful:<br />
* <b>git status</b>: allows you to see which files were changed in your repository<br />
* <b>git add -i</b>: opens an interface that allows you to choose which files to add in bulk<br />
* <b>git stash</b>: if you have unstaged changes in your local repository you wont be able to rebase after a fetch, or you will loose them if you switch branches. The stash command pu those changes away to be retrieved later. A new folder "Stashed Commits" will be created and your unstaged changes put in the Stash@{0} folder. It is useful to know that each new stash will take the Stash@{0} name and increment the anterior ones index by 1 ( Stash@{1}, ... )<br />
* <b>git stash list</b>: will list all the stash you have in store<br />
* <b>git branch</b>: will list all the branches created in your local git and notify you where you are<br />
* <b>git branch -vv</b>: will show you all your branches and the remote they are based on<br />
* <b>git log -n</b>: will display the last "n" commits that happened in your branch<br />
* <b>git log -n --pretty=oneline</b>: just as above but will show each one on a single line, useful if you want to display a lot of them<br />
* <b>git reset --soft HEAD~n</b>: rewind the last "n" actions done on your branch. Only use this to correct your own mistakes as it can lead to annoying situations<br />
* <b>git reset --hard [remote]</b>: resets the local branch to look like the remote. Again be careful as any changes on your end will be erased <br />
<br />
As a reminder here are some Git related commands, just in case:<br />
* <b>git clone [remote uri] [local path]</b>: clone the git repository at the uri address mentioned<br />
* <b>git remote add [name] [remote uri]</b>: add a new remote<br />
* <b>git checkout [name of the local branch]</b>: switch to the mentioned branch<br />
* <b>git checkout -b [name of the local branch] [remote uri]</b>: create a new local branch from the remote<br />
* <b>git branch --set-upstream [name of the remote]</b>: will set the new remote as the upstream for this branch<br />
<br />
Of course, don"t forget the very useful command:<br />
* <b>man git</b>: allows you to access all the possible commands with a brief explanation of their purpose<br />
<br />
<br /><br />
<br />
==== VI Commands ====<br />
And if you use the VI editor:<br />
There are two "modes", one for editing (inserting) and one for navigating through the file, that we will call "I mode" and "Esc mode" respectively. Each of them are entered by pressing the associated key and exited by pressing its counterpart.<br />
* <b>i</b> (I mode): allows you to edit a line. Be aware that the text will be inserted before the cursor<br />
* <b>dd</b> (Esc mode): allows you to delete a line<br />
* <b>x</b> (Esc mode): delete a character<br />
* <b>o</b> (Esc mode): insert blank line<br />
* <b>u</b> (Esc mode): undo last changes<br />
<br />
* <b>:w</b> (Esc mode): saves the changes in the file<br />
* <b>:wq</b> (Esc mode): saves the changes and exits the editor<br />
* <b>:q!</b> (Esc mode): exits the editor without saving anything<br />
<br />
<br /><br />
<br />
More information of how to use git on [https://wiki.eclipse.org/Development_Resources/Contributing_via_Git Contributing via Git]<br />
<br />
<br />
==== Mylyn Configuration ====<br />
Here is a basic example of how to configure mylyn to receive the bugs associated withe Papyrus:<br />
First, after installing the mylyn connector just as you would any other new software (Help>Install New Software), open the mylyn view (Window>Show View). From there select the <b>New Query</b> option and proceed as illustrated below.<br />
<br />
[[File:mylyn_Config1.png | 600px]]<br />
<br />
[[File:mylyn_Config2.png | 600px]]<br />
<br />
[[File:mylyn_Config3.png | 600px]]<br />
<br />
<br />
As a side note you can file bugs directly from mylyn using the <b>New Task</b> option from the Task Repositories view. Then, proceed to fill the requiered fields corresponding to your use case and submit the newly created bug.<br />
<br />
[[File:mylyn_Bug1.png | 600px]]<br />
<br />
[[File:mylyn_Bug2.png | 600px]]<br />
<br />
[[File:mylyn_Bug3.png | 600px]]</div>Patrick.Tessier.cea.frhttps://wiki.eclipse.org/index.php?title=Papyrus/2020.12_Work_Description&diff=442000Papyrus/2020.12 Work Description2020-12-08T09:31:27Z<p>Patrick.Tessier.cea.fr: </p>
<hr />
<div>All the work realized by CEA LIST is sponsored by CEA LIST. All bugs, or feature may be found in the tracker[https://projects.eclipse.org/projects/modeling.mdt.papyrus/releases/5.0.0/bugs] .<br />
<br />
Papyrus 5.0 contains new features:<br />
<br />
It is now possible to associate a set of customization of the model explorer to the architecture framework.<br />
<br />
A huge job has been done to remove all re-exports on dependencies.<br />
<br />
Now papyrus 5.0 compiles on Java11.<br />
<br />
Note that all the relative: Sysml 1.4, 1.6, Moka, designer... have also been reworked to be compatible with work on re-exports and on Java11.</div>Patrick.Tessier.cea.frhttps://wiki.eclipse.org/index.php?title=Papyrus/2020.12_Work_Description&diff=441999Papyrus/2020.12 Work Description2020-12-08T09:30:57Z<p>Patrick.Tessier.cea.fr: </p>
<hr />
<div>All the work realized by CEA LIST is sponsored by CEA LIST. All bugs, or feature may be found in the tracker[https://projects.eclipse.org/projects/modeling.mdt.papyrus/releases/5.0.0/bugs] .<br />
<br />
Papyrus 5.0 contains new features:<br />
<br />
It is now possible to associate a set of customization of the model explorer to the architecture framework.<br />
A huge job has been done to remove all re-exports on dependencies.<br />
Now papyrus 5.0 compiles on Java11.<br />
Note that all the relative: Sysml 1.4, 1.6, Moka, designer... have also been reworked to be compatible with work on re-exports and on Java11.</div>Patrick.Tessier.cea.frhttps://wiki.eclipse.org/index.php?title=Papyrus&diff=441998Papyrus2020-12-08T09:23:46Z<p>Patrick.Tessier.cea.fr: /* About Releases (4.X) */</p>
<hr />
<div>=Overview=<br />
[https://eclipse.org/papyrus/ Papyrus] is an open source project to provide an integrated environment for editing [[MDT-UML2|UML]] and [https://www.eclipse.org/papyrus/components/sysml/ SysML] models. Specially, this project provides the glue around valuable UML and SysML diagram editors ([[GMF]]-based or not) and other MDE tools. It also offers support for UML and SysML profiling mechanisms. <br />
<br />
You can explore Papyrus's galaxy here [https://eclipse.org/papyrus/ https://eclipse.org/papyrus/].<br />
<br />
=Documentation=<br />
<br />
* Initial project description : [[MDT/Papyrus-Proposal | Papyrus component proposal]]<br />
* Guides<br />
** [https://help.eclipse.org/2020-09/index.jsp?nav=%2F73_0 2020/09 Papyrus User Guide]<br />
** [[Papyrus User Guide|User Guide]]<br />
** [[Papyrus/Papyrus Developer Guide | Developer Guide]]<br />
* Migration Guides<br />
** Migration guide 4.x to 5.x is coming soon <br />
** [[Papyrus/Migration Guide/Oxygen | Papyrus Oxygen (3.0) Migration Guide]]<br />
** [[Papyrus/Migration Guide/Neon | Papyrus Neon (2.0) Migration Guide]] — [[Media:Papyrus_Neon_Migration_Guide.pdf|as printable PDF]]<br />
<br />
<!--* Miscellaneous<br />
** [[General Architecture | General Architecture]]<br />
** [[Eclipse Papyrus FAQ|Eclipse Papyrus FAQ]]--><br />
<br />
=Papyrus Ecosystems=<br />
<br />
* Papyrus4<br />
** [[Papyrus for Information Modeling | Papyrus4Information Modeling ]]<br />
** [[Papyrus for Education | Papyrus4Education]]<br />
* Papyrus Components<br />
** [https://www.eclipse.org/papyrus/components/designer/ Designer]<br />
** [https://www.eclipse.org/papyrus/components/robotml RobotML]<br />
** [https://www.eclipse.org/papyrus/components/sysml/ SysML]<br />
** [https://www.eclipse.org/papyrus/components/marte/ Marte]<br />
** [https://wiki.eclipse.org/Papyrus/UserGuide/ModelExecution Moka]<br />
** [https://www.eclipse.org/papyrus/components/components/ Components]<br />
<br />
<br />
=Road Map and Tasks=<br />
==Next Major release :2020-12==<br />
<br />
We will now begin to work on the next major release of papyrus (5.0.0) in order to allow us some API changes and other corrections. This version will be available in time to integrate the '''2020-12 release train'''.<br />
<br />
Because we need to focus on this goal, there is no release planned for the 2020-09 train. <br />
<br />
The 5.0.0 release will contain, for example, the refactoring of some dependencies such as removing the reexports wherever possible and removing deprecated APIs lingering for far too long in the code base.<br />
<br />
We will inform you about any work undertaken on the wiki page [[Papyrus/2020.12 Work Description | Incoming work for 2020-12]].<br />
<br />
==About Releases (5.X)==<br />
* [[Papyrus/2020.12 Work Description | Incoming work for 2020.12]]<br />
<br />
==About Releases (4.X)==<br />
* [[Papyrus/2020.06 Work Description | Incoming work for 2020.06]]<br />
* [[Papyrus/2020.03 Work Description | Incoming work for 2020.03]]<br />
* [[Papyrus/2019.12 Work Description | Incoming work for 2019.12]]<br />
* [[Papyrus/2019.09 Work Description | Incoming work for 2019.09]]<br />
* [[Papyrus/2019.06 Work Description | Incoming work for 2019.06]]<br />
* [[Papyrus/2019.03 Work Description | Incoming work for 2019.03]]<br />
* [[Papyrus/2018.12 Work Description | Incoming work for 2018.12]]<br />
* [[Papyrus/2018.9 Work Description | Incoming work for 2018.9]]<br />
* [[Papyrus/Photon Work Description | Incoming work for Photon]]<br />
<br />
<br />
* [[Papyrus/Archives | Incoming works for previous releases]]<br />
<br />
=Team=<br />
The project committers are:<br />
* Ansgar Radermacher (CEA)<br />
* Camille Letavernier (EclipseSource) <br />
* Christian W. Damus (independant)<br />
* Florian Noyrit (CEA)<br />
* Jeremie Tatibouet (CEA)<br />
* Patrick Tessier (CEA)<br />
* Pauline Deville (CEA)<br />
* Quentin Le Menez (CEA)<br />
* Remi Schnekenburger (EclipseSource) <br />
* Shuai Li (CEA)<br />
* Vincent Lorenzo (CEA)<br />
<br />
<br/>Committers Emeritus:<br />
* Arnaud Cuccuru (CEA)<br />
* Arthur Daussy (ATOS)<br />
* Benoit Maggi (independant)<br />
* Cedric Dumoulin (LIFL)<br />
* Chokri Mraidha (CEA)<br />
* Juan Cadavid (CEA)<br />
* Mickael Adam (All4Tec)<br />
* Nicolas Fauvergue (independant)<br />
* Raphael Faudou (Samares)<br />
* Saadia Dhouib (CEA)<br />
* Sebastien Gerard (CEA – Project lead)<br />
* Tristan Faure (independant)<br />
<br />
=Contacts= <br />
<br />
You can browse the Papyrus git repositories at [https://git.eclipse.org/c/papyrus/ https://git.eclipse.org/c/papyrus/].<br />
<br />
Any issue should be reported using [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Papyrus Bugzilla].<br />
<br />
You may also contact the team using forums or mailing list:<br />
* [http://www.eclipse.org/forums/index.php?t=thread&frm_id=121 Papyrus forums]<br />
* [https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev Developer Mailing List] ([https://dev.eclipse.org/mhonarc/lists/mdt-papyrus.dev/ Mailing list Archive])<br />
<br />
<br />
[[Category:Modeling]]<br />
[[Category:Papyrus]]</div>Patrick.Tessier.cea.frhttps://wiki.eclipse.org/index.php?title=Papyrus&diff=441997Papyrus2020-12-08T09:23:30Z<p>Patrick.Tessier.cea.fr: /* About Releases (4.X) */</p>
<hr />
<div>=Overview=<br />
[https://eclipse.org/papyrus/ Papyrus] is an open source project to provide an integrated environment for editing [[MDT-UML2|UML]] and [https://www.eclipse.org/papyrus/components/sysml/ SysML] models. Specially, this project provides the glue around valuable UML and SysML diagram editors ([[GMF]]-based or not) and other MDE tools. It also offers support for UML and SysML profiling mechanisms. <br />
<br />
You can explore Papyrus's galaxy here [https://eclipse.org/papyrus/ https://eclipse.org/papyrus/].<br />
<br />
=Documentation=<br />
<br />
* Initial project description : [[MDT/Papyrus-Proposal | Papyrus component proposal]]<br />
* Guides<br />
** [https://help.eclipse.org/2020-09/index.jsp?nav=%2F73_0 2020/09 Papyrus User Guide]<br />
** [[Papyrus User Guide|User Guide]]<br />
** [[Papyrus/Papyrus Developer Guide | Developer Guide]]<br />
* Migration Guides<br />
** Migration guide 4.x to 5.x is coming soon <br />
** [[Papyrus/Migration Guide/Oxygen | Papyrus Oxygen (3.0) Migration Guide]]<br />
** [[Papyrus/Migration Guide/Neon | Papyrus Neon (2.0) Migration Guide]] — [[Media:Papyrus_Neon_Migration_Guide.pdf|as printable PDF]]<br />
<br />
<!--* Miscellaneous<br />
** [[General Architecture | General Architecture]]<br />
** [[Eclipse Papyrus FAQ|Eclipse Papyrus FAQ]]--><br />
<br />
=Papyrus Ecosystems=<br />
<br />
* Papyrus4<br />
** [[Papyrus for Information Modeling | Papyrus4Information Modeling ]]<br />
** [[Papyrus for Education | Papyrus4Education]]<br />
* Papyrus Components<br />
** [https://www.eclipse.org/papyrus/components/designer/ Designer]<br />
** [https://www.eclipse.org/papyrus/components/robotml RobotML]<br />
** [https://www.eclipse.org/papyrus/components/sysml/ SysML]<br />
** [https://www.eclipse.org/papyrus/components/marte/ Marte]<br />
** [https://wiki.eclipse.org/Papyrus/UserGuide/ModelExecution Moka]<br />
** [https://www.eclipse.org/papyrus/components/components/ Components]<br />
<br />
<br />
=Road Map and Tasks=<br />
==Next Major release :2020-12==<br />
<br />
We will now begin to work on the next major release of papyrus (5.0.0) in order to allow us some API changes and other corrections. This version will be available in time to integrate the '''2020-12 release train'''.<br />
<br />
Because we need to focus on this goal, there is no release planned for the 2020-09 train. <br />
<br />
The 5.0.0 release will contain, for example, the refactoring of some dependencies such as removing the reexports wherever possible and removing deprecated APIs lingering for far too long in the code base.<br />
<br />
We will inform you about any work undertaken on the wiki page [[Papyrus/2020.12 Work Description | Incoming work for 2020-12]].<br />
<br />
==About Releases (5.X)==<br />
* [[Papyrus/2020.12 Work Description | Incoming work for 2020.12]]<br />
<br />
==About Releases (4.X)==<br />
* [[Papyrus/2020.12 Work Description | Incoming work for 2020.12]]<br />
* [[Papyrus/2020.06 Work Description | Incoming work for 2020.06]]<br />
* [[Papyrus/2020.03 Work Description | Incoming work for 2020.03]]<br />
* [[Papyrus/2019.12 Work Description | Incoming work for 2019.12]]<br />
* [[Papyrus/2019.09 Work Description | Incoming work for 2019.09]]<br />
* [[Papyrus/2019.06 Work Description | Incoming work for 2019.06]]<br />
* [[Papyrus/2019.03 Work Description | Incoming work for 2019.03]]<br />
* [[Papyrus/2018.12 Work Description | Incoming work for 2018.12]]<br />
* [[Papyrus/2018.9 Work Description | Incoming work for 2018.9]]<br />
* [[Papyrus/Photon Work Description | Incoming work for Photon]]<br />
<br />
<br />
* [[Papyrus/Archives | Incoming works for previous releases]]<br />
<br />
=Team=<br />
The project committers are:<br />
* Ansgar Radermacher (CEA)<br />
* Camille Letavernier (EclipseSource) <br />
* Christian W. Damus (independant)<br />
* Florian Noyrit (CEA)<br />
* Jeremie Tatibouet (CEA)<br />
* Patrick Tessier (CEA)<br />
* Pauline Deville (CEA)<br />
* Quentin Le Menez (CEA)<br />
* Remi Schnekenburger (EclipseSource) <br />
* Shuai Li (CEA)<br />
* Vincent Lorenzo (CEA)<br />
<br />
<br/>Committers Emeritus:<br />
* Arnaud Cuccuru (CEA)<br />
* Arthur Daussy (ATOS)<br />
* Benoit Maggi (independant)<br />
* Cedric Dumoulin (LIFL)<br />
* Chokri Mraidha (CEA)<br />
* Juan Cadavid (CEA)<br />
* Mickael Adam (All4Tec)<br />
* Nicolas Fauvergue (independant)<br />
* Raphael Faudou (Samares)<br />
* Saadia Dhouib (CEA)<br />
* Sebastien Gerard (CEA – Project lead)<br />
* Tristan Faure (independant)<br />
<br />
=Contacts= <br />
<br />
You can browse the Papyrus git repositories at [https://git.eclipse.org/c/papyrus/ https://git.eclipse.org/c/papyrus/].<br />
<br />
Any issue should be reported using [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Papyrus Bugzilla].<br />
<br />
You may also contact the team using forums or mailing list:<br />
* [http://www.eclipse.org/forums/index.php?t=thread&frm_id=121 Papyrus forums]<br />
* [https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev Developer Mailing List] ([https://dev.eclipse.org/mhonarc/lists/mdt-papyrus.dev/ Mailing list Archive])<br />
<br />
<br />
[[Category:Modeling]]<br />
[[Category:Papyrus]]</div>Patrick.Tessier.cea.frhttps://wiki.eclipse.org/index.php?title=Papyrus&diff=441771Papyrus2020-11-26T13:40:54Z<p>Patrick.Tessier.cea.fr: /* Documentation */</p>
<hr />
<div>=Overview=<br />
[https://eclipse.org/papyrus/ Papyrus] is an open source project to provide an integrated environment for editing [[MDT-UML2|UML]] and [https://www.eclipse.org/papyrus/components/sysml/ SysML] models. Specially, this project provides the glue around valuable UML and SysML diagram editors ([[GMF]]-based or not) and other MDE tools. It also offers support for UML and SysML profiling mechanisms. <br />
<br />
You can explore Papyrus's galaxy here [https://eclipse.org/papyrus/ https://eclipse.org/papyrus/].<br />
<br />
=Documentation=<br />
<br />
* Initial project description : [[MDT/Papyrus-Proposal | Papyrus component proposal]]<br />
* Guides<br />
** [https://help.eclipse.org/2020-09/index.jsp?nav=%2F73_0 2020/09 Papyrus User Guide]<br />
** [[Papyrus User Guide|User Guide]]<br />
** [[Papyrus/Papyrus Developer Guide | Developer Guide]]<br />
* Migration Guides<br />
** Migration guide 4.x to 5.x is coming soon <br />
** [[Papyrus/Migration Guide/Oxygen | Papyrus Oxygen (3.0) Migration Guide]]<br />
** [[Papyrus/Migration Guide/Neon | Papyrus Neon (2.0) Migration Guide]] — [[Media:Papyrus_Neon_Migration_Guide.pdf|as printable PDF]]<br />
<br />
<!--* Miscellaneous<br />
** [[General Architecture | General Architecture]]<br />
** [[Eclipse Papyrus FAQ|Eclipse Papyrus FAQ]]--><br />
<br />
=Papyrus Ecosystems=<br />
<br />
* Papyrus4<br />
** [[Papyrus for Information Modeling | Papyrus4Information Modeling ]]<br />
** [[Papyrus for Education | Papyrus4Education]]<br />
* Papyrus Components<br />
** [https://www.eclipse.org/papyrus/components/designer/ Designer]<br />
** [https://www.eclipse.org/papyrus/components/robotml RobotML]<br />
** [https://www.eclipse.org/papyrus/components/sysml/ SysML]<br />
** [https://www.eclipse.org/papyrus/components/marte/ Marte]<br />
** [https://wiki.eclipse.org/Papyrus/UserGuide/ModelExecution Moka]<br />
** [https://www.eclipse.org/papyrus/components/components/ Components]<br />
<br />
<br />
=Road Map and Tasks=<br />
==Next Major release :2020-12==<br />
<br />
We will now begin to work on the next major release of papyrus (5.0.0) in order to allow us some API changes and other corrections. This version will be available in time to integrate the '''2020-12 release train'''.<br />
<br />
Because we need to focus on this goal, there is no release planned for the 2020-09 train. <br />
<br />
The 5.0.0 release will contain, for example, the refactoring of some dependencies such as removing the reexports wherever possible and removing deprecated APIs lingering for far too long in the code base.<br />
<br />
We will inform you about any work undertaken on the wiki page [[Papyrus/2020.12 Work Description | Incoming work for 2020-12]].<br />
<br />
==About Releases (5.X)==<br />
* [[Papyrus/2020.12 Work Description | Incoming work for 2020.12]]<br />
<br />
==About Releases (4.X)==<br />
* [[Papyrus/2020.06 Work Description | Incoming work for 2020.06]]<br />
* [[Papyrus/2020.03 Work Description | Incoming work for 2020.03]]<br />
* [[Papyrus/2019.12 Work Description | Incoming work for 2019.12]]<br />
* [[Papyrus/2019.09 Work Description | Incoming work for 2019.09]]<br />
* [[Papyrus/2019.06 Work Description | Incoming work for 2019.06]]<br />
* [[Papyrus/2019.03 Work Description | Incoming work for 2019.03]]<br />
* [[Papyrus/2018.12 Work Description | Incoming work for 2018.12]]<br />
* [[Papyrus/2018.9 Work Description | Incoming work for 2018.9]]<br />
* [[Papyrus/Photon Work Description | Incoming work for Photon]]<br />
<br />
<br />
* [[Papyrus/Archives | Incoming works for previous releases]]<br />
<br />
=Team=<br />
The project committers are:<br />
* Ansgar Radermacher (CEA)<br />
* Camille Letavernier (EclipseSource) <br />
* Christian W. Damus (independant)<br />
* Florian Noyrit (CEA)<br />
* Jeremie Tatibouet (CEA)<br />
* Patrick Tessier (CEA)<br />
* Pauline Deville (CEA)<br />
* Quentin Le Menez (CEA)<br />
* Remi Schnekenburger (EclipseSource) <br />
* Shuai Li (CEA)<br />
* Vincent Lorenzo (CEA)<br />
<br />
<br/>Committers Emeritus:<br />
* Arnaud Cuccuru (CEA)<br />
* Arthur Daussy (ATOS)<br />
* Benoit Maggi (independant)<br />
* Cedric Dumoulin (LIFL)<br />
* Chokri Mraidha (CEA)<br />
* Juan Cadavid (CEA)<br />
* Mickael Adam (All4Tec)<br />
* Nicolas Fauvergue (independant)<br />
* Raphael Faudou (Samares)<br />
* Saadia Dhouib (CEA)<br />
* Sebastien Gerard (CEA – Project lead)<br />
* Tristan Faure (independant)<br />
<br />
=Contacts= <br />
<br />
You can browse the Papyrus git repositories at [https://git.eclipse.org/c/papyrus/ https://git.eclipse.org/c/papyrus/].<br />
<br />
Any issue should be reported using [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Papyrus Bugzilla].<br />
<br />
You may also contact the team using forums or mailing list:<br />
* [http://www.eclipse.org/forums/index.php?t=thread&frm_id=121 Papyrus forums]<br />
* [https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev Developer Mailing List] ([https://dev.eclipse.org/mhonarc/lists/mdt-papyrus.dev/ Mailing list Archive])<br />
<br />
<br />
[[Category:Modeling]]<br />
[[Category:Papyrus]]</div>Patrick.Tessier.cea.frhttps://wiki.eclipse.org/index.php?title=Papyrus&diff=441769Papyrus2020-11-26T13:35:51Z<p>Patrick.Tessier.cea.fr: /* Documentation */</p>
<hr />
<div>=Overview=<br />
[https://eclipse.org/papyrus/ Papyrus] is an open source project to provide an integrated environment for editing [[MDT-UML2|UML]] and [https://www.eclipse.org/papyrus/components/sysml/ SysML] models. Specially, this project provides the glue around valuable UML and SysML diagram editors ([[GMF]]-based or not) and other MDE tools. It also offers support for UML and SysML profiling mechanisms. <br />
<br />
You can explore Papyrus's galaxy here [https://eclipse.org/papyrus/ https://eclipse.org/papyrus/].<br />
<br />
=Documentation=<br />
<br />
* Initial project description : [[MDT/Papyrus-Proposal | Papyrus component proposal]]<br />
* Guides<br />
** [[Papyrus User Guide|User Guide]]<br />
** [[Papyrus/Papyrus Developer Guide | Developer Guide]]<br />
* Migration Guides<br />
** Migration guide 4.x to 5.x is coming soon <br />
** [[Papyrus/Migration Guide/Oxygen | Papyrus Oxygen (3.0) Migration Guide]]<br />
** [[Papyrus/Migration Guide/Neon | Papyrus Neon (2.0) Migration Guide]] — [[Media:Papyrus_Neon_Migration_Guide.pdf|as printable PDF]]<br />
<br />
<!--* Miscellaneous<br />
** [[General Architecture | General Architecture]]<br />
** [[Eclipse Papyrus FAQ|Eclipse Papyrus FAQ]]--><br />
<br />
=Papyrus Ecosystems=<br />
<br />
* Papyrus4<br />
** [[Papyrus for Information Modeling | Papyrus4Information Modeling ]]<br />
** [[Papyrus for Education | Papyrus4Education]]<br />
* Papyrus Components<br />
** [https://www.eclipse.org/papyrus/components/designer/ Designer]<br />
** [https://www.eclipse.org/papyrus/components/robotml RobotML]<br />
** [https://www.eclipse.org/papyrus/components/sysml/ SysML]<br />
** [https://www.eclipse.org/papyrus/components/marte/ Marte]<br />
** [https://wiki.eclipse.org/Papyrus/UserGuide/ModelExecution Moka]<br />
** [https://www.eclipse.org/papyrus/components/components/ Components]<br />
<br />
<br />
=Road Map and Tasks=<br />
==Next Major release :2020-12==<br />
<br />
We will now begin to work on the next major release of papyrus (5.0.0) in order to allow us some API changes and other corrections. This version will be available in time to integrate the '''2020-12 release train'''.<br />
<br />
Because we need to focus on this goal, there is no release planned for the 2020-09 train. <br />
<br />
The 5.0.0 release will contain, for example, the refactoring of some dependencies such as removing the reexports wherever possible and removing deprecated APIs lingering for far too long in the code base.<br />
<br />
We will inform you about any work undertaken on the wiki page [[Papyrus/2020.12 Work Description | Incoming work for 2020-12]].<br />
<br />
==About Releases (5.X)==<br />
* [[Papyrus/2020.12 Work Description | Incoming work for 2020.12]]<br />
<br />
==About Releases (4.X)==<br />
* [[Papyrus/2020.06 Work Description | Incoming work for 2020.06]]<br />
* [[Papyrus/2020.03 Work Description | Incoming work for 2020.03]]<br />
* [[Papyrus/2019.12 Work Description | Incoming work for 2019.12]]<br />
* [[Papyrus/2019.09 Work Description | Incoming work for 2019.09]]<br />
* [[Papyrus/2019.06 Work Description | Incoming work for 2019.06]]<br />
* [[Papyrus/2019.03 Work Description | Incoming work for 2019.03]]<br />
* [[Papyrus/2018.12 Work Description | Incoming work for 2018.12]]<br />
* [[Papyrus/2018.9 Work Description | Incoming work for 2018.9]]<br />
* [[Papyrus/Photon Work Description | Incoming work for Photon]]<br />
<br />
<br />
* [[Papyrus/Archives | Incoming works for previous releases]]<br />
<br />
=Team=<br />
The project committers are:<br />
* Ansgar Radermacher (CEA)<br />
* Camille Letavernier (EclipseSource) <br />
* Christian W. Damus (independant)<br />
* Florian Noyrit (CEA)<br />
* Jeremie Tatibouet (CEA)<br />
* Patrick Tessier (CEA)<br />
* Pauline Deville (CEA)<br />
* Quentin Le Menez (CEA)<br />
* Remi Schnekenburger (EclipseSource) <br />
* Shuai Li (CEA)<br />
* Vincent Lorenzo (CEA)<br />
<br />
<br/>Committers Emeritus:<br />
* Arnaud Cuccuru (CEA)<br />
* Arthur Daussy (ATOS)<br />
* Benoit Maggi (independant)<br />
* Cedric Dumoulin (LIFL)<br />
* Chokri Mraidha (CEA)<br />
* Juan Cadavid (CEA)<br />
* Mickael Adam (All4Tec)<br />
* Nicolas Fauvergue (independant)<br />
* Raphael Faudou (Samares)<br />
* Saadia Dhouib (CEA)<br />
* Sebastien Gerard (CEA – Project lead)<br />
* Tristan Faure (independant)<br />
<br />
=Contacts= <br />
<br />
You can browse the Papyrus git repositories at [https://git.eclipse.org/c/papyrus/ https://git.eclipse.org/c/papyrus/].<br />
<br />
Any issue should be reported using [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Papyrus Bugzilla].<br />
<br />
You may also contact the team using forums or mailing list:<br />
* [http://www.eclipse.org/forums/index.php?t=thread&frm_id=121 Papyrus forums]<br />
* [https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev Developer Mailing List] ([https://dev.eclipse.org/mhonarc/lists/mdt-papyrus.dev/ Mailing list Archive])<br />
<br />
<br />
[[Category:Modeling]]<br />
[[Category:Papyrus]]</div>Patrick.Tessier.cea.frhttps://wiki.eclipse.org/index.php?title=Papyrus&diff=441768Papyrus2020-11-26T13:33:05Z<p>Patrick.Tessier.cea.fr: /* Documentation */</p>
<hr />
<div>=Overview=<br />
[https://eclipse.org/papyrus/ Papyrus] is an open source project to provide an integrated environment for editing [[MDT-UML2|UML]] and [https://www.eclipse.org/papyrus/components/sysml/ SysML] models. Specially, this project provides the glue around valuable UML and SysML diagram editors ([[GMF]]-based or not) and other MDE tools. It also offers support for UML and SysML profiling mechanisms. <br />
<br />
You can explore Papyrus's galaxy here [https://eclipse.org/papyrus/ https://eclipse.org/papyrus/].<br />
<br />
=Documentation=<br />
<br />
* Initial project description : [[MDT/Papyrus-Proposal | Papyrus component proposal]]<br />
* Guides<br />
** [[Papyrus User Guide|User Guide]]<br />
** [[Papyrus/Papyrus Developer Guide | Developer Guide]]<br />
* Migration Guides<br />
** [[Papyrus/Migration Guide/Oxygen | Papyrus Oxygen (3.0) Migration Guide]]<br />
** [[Papyrus/Migration Guide/Neon | Papyrus Neon (2.0) Migration Guide]] — [[Media:Papyrus_Neon_Migration_Guide.pdf|as printable PDF]]<br />
<br />
<!--* Miscellaneous<br />
** [[General Architecture | General Architecture]]<br />
** [[Eclipse Papyrus FAQ|Eclipse Papyrus FAQ]]--><br />
<br />
=Papyrus Ecosystems=<br />
<br />
* Papyrus4<br />
** [[Papyrus for Information Modeling | Papyrus4Information Modeling ]]<br />
** [[Papyrus for Education | Papyrus4Education]]<br />
* Papyrus Components<br />
** [https://www.eclipse.org/papyrus/components/designer/ Designer]<br />
** [https://www.eclipse.org/papyrus/components/robotml RobotML]<br />
** [https://www.eclipse.org/papyrus/components/sysml/ SysML]<br />
** [https://www.eclipse.org/papyrus/components/marte/ Marte]<br />
** [https://wiki.eclipse.org/Papyrus/UserGuide/ModelExecution Moka]<br />
** [https://www.eclipse.org/papyrus/components/components/ Components]<br />
<br />
<br />
=Road Map and Tasks=<br />
==Next Major release :2020-12==<br />
<br />
We will now begin to work on the next major release of papyrus (5.0.0) in order to allow us some API changes and other corrections. This version will be available in time to integrate the '''2020-12 release train'''.<br />
<br />
Because we need to focus on this goal, there is no release planned for the 2020-09 train. <br />
<br />
The 5.0.0 release will contain, for example, the refactoring of some dependencies such as removing the reexports wherever possible and removing deprecated APIs lingering for far too long in the code base.<br />
<br />
We will inform you about any work undertaken on the wiki page [[Papyrus/2020.12 Work Description | Incoming work for 2020-12]].<br />
<br />
==About Releases (5.X)==<br />
* [[Papyrus/2020.12 Work Description | Incoming work for 2020.12]]<br />
<br />
==About Releases (4.X)==<br />
* [[Papyrus/2020.06 Work Description | Incoming work for 2020.06]]<br />
* [[Papyrus/2020.03 Work Description | Incoming work for 2020.03]]<br />
* [[Papyrus/2019.12 Work Description | Incoming work for 2019.12]]<br />
* [[Papyrus/2019.09 Work Description | Incoming work for 2019.09]]<br />
* [[Papyrus/2019.06 Work Description | Incoming work for 2019.06]]<br />
* [[Papyrus/2019.03 Work Description | Incoming work for 2019.03]]<br />
* [[Papyrus/2018.12 Work Description | Incoming work for 2018.12]]<br />
* [[Papyrus/2018.9 Work Description | Incoming work for 2018.9]]<br />
* [[Papyrus/Photon Work Description | Incoming work for Photon]]<br />
<br />
<br />
* [[Papyrus/Archives | Incoming works for previous releases]]<br />
<br />
=Team=<br />
The project committers are:<br />
* Ansgar Radermacher (CEA)<br />
* Camille Letavernier (EclipseSource) <br />
* Christian W. Damus (independant)<br />
* Florian Noyrit (CEA)<br />
* Jeremie Tatibouet (CEA)<br />
* Patrick Tessier (CEA)<br />
* Pauline Deville (CEA)<br />
* Quentin Le Menez (CEA)<br />
* Remi Schnekenburger (EclipseSource) <br />
* Shuai Li (CEA)<br />
* Vincent Lorenzo (CEA)<br />
<br />
<br/>Committers Emeritus:<br />
* Arnaud Cuccuru (CEA)<br />
* Arthur Daussy (ATOS)<br />
* Benoit Maggi (independant)<br />
* Cedric Dumoulin (LIFL)<br />
* Chokri Mraidha (CEA)<br />
* Juan Cadavid (CEA)<br />
* Mickael Adam (All4Tec)<br />
* Nicolas Fauvergue (independant)<br />
* Raphael Faudou (Samares)<br />
* Saadia Dhouib (CEA)<br />
* Sebastien Gerard (CEA – Project lead)<br />
* Tristan Faure (independant)<br />
<br />
=Contacts= <br />
<br />
You can browse the Papyrus git repositories at [https://git.eclipse.org/c/papyrus/ https://git.eclipse.org/c/papyrus/].<br />
<br />
Any issue should be reported using [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Papyrus Bugzilla].<br />
<br />
You may also contact the team using forums or mailing list:<br />
* [http://www.eclipse.org/forums/index.php?t=thread&frm_id=121 Papyrus forums]<br />
* [https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev Developer Mailing List] ([https://dev.eclipse.org/mhonarc/lists/mdt-papyrus.dev/ Mailing list Archive])<br />
<br />
<br />
[[Category:Modeling]]<br />
[[Category:Papyrus]]</div>Patrick.Tessier.cea.frhttps://wiki.eclipse.org/index.php?title=Papyrus_Obfuscation_Guide&diff=441767Papyrus Obfuscation Guide2020-11-26T13:32:21Z<p>Patrick.Tessier.cea.fr: Replaced content with "should be deleted Category:Papyrus"</p>
<hr />
<div>should be deleted<br />
<br />
[[Category:Papyrus]]</div>Patrick.Tessier.cea.frhttps://wiki.eclipse.org/index.php?title=Papyrus/Papyrus_Developer_Guide/How_To-_Code_Contributing&diff=440997Papyrus/Papyrus Developer Guide/How To- Code Contributing2020-09-28T09:12:04Z<p>Patrick.Tessier.cea.fr: /* Code Rules */</p>
<hr />
<div>__TOC__<br />
<br />
<br />
All papyrus contributors shall follow these rules:<br />
<br />
== Write a Bugzilla task ==<br />
When adding a task to the buzilla, the following grammar should be used: <br />
<br />
*'[' ''Category'' ']' ''NameOfTheTask''<br><br />
<br />
The category helps to filter the bugs for developers. There are already some existing categories: General, XXX Diagram, Common, Property View, etc.<br />
<br />
As a reminder, the lifecycle of bugs is located here: [[Development Resources/HOWTO/Bugzilla Use|Bugzilla Use]]<br />
<br />
*Your contribution shall be associated to a bug refenced in the bugzilla.<br />
*When a bug is opened/resolved/closed the Target Milestone must be filled. For example the bug has been fixed for the service release 3 of oxygen, the target milestone is 3.3.<br />
<br />
<br />
== Write the code ==<br />
<br />
=== Papyrus Plugin Structure ===<br />
<br />
*Papyrus plugin naming scheme and folder structure used to locate and name plugins is described here: [[Papyrus/Papyrus_Developer_Guide/Papyrus_Plugin_Naming_Scheme]]<br />
<br />
*All plug-ins must compile and run against JavaSE-1.8. Papyrus 5.0 must compile against openjdk-11.<br />
*Plug-in provider&nbsp;: ''Eclipse Modeling Project'' <br />
*Version&nbsp;: <br />
***Papyrus adheres to the [[Version Numbering|Eclipse Versioning Guidelines]] for API evolution and other kinds of changes''<br />
*Plug-in name&nbsp;: must end with (Incubation) if version is less than 1.0.0 . If the version is at least 1.0.0, the (Incubation) suffix must be removed.<br />
*Plug-in ID&nbsp;: must start with org.eclipse.papyrus.<br />
*Plug-in dependencies must not be re-exported.<br />
*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"'')<br />
**The Papyrus Developer Tools has 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<br />
*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: <br />
**META-INF/ <br />
**about.html <br />
**icons/, images/, resources/, models/, etc. (All folders containing runtime resources) <br />
**plugin.properties <br />
**plugin.xml <br />
**schema/ <br />
*Do '''not''' include the following files: <br />
**.classpath <br />
**.project <br />
**bin/, src/, src-gen/, custom-src/ <br />
**build.properties <br />
*The ''Source build'' (field src.includes in build.properties) category '''must''' contain the '''about.html''' file: <br />
*It '''must not''' contain the following: <br />
**src/, src-gen/, custom-src/ <br />
**All files and directories are already contained in the "Binary build" category (Except the about.html which must be contained in both Binary and Source builds)<br />
<br />
plugin.xml:<br><br />
[[Image:Papyrus.codestandards.plugin.xml.png]]<br />
<br />
=== Papyrus Feature Structure ===<br />
<br />
* Papyrus feature id scheme: org.eclipse.papyrus.&lt;feature.name&gt;.feature <br />
**e.g. ''org.eclipse.papyrus.infra.core.feature'' <br />
* Papyrus feature Label scheme: Papyrus &lt;Feature Name&gt;<br />
**e.g. ''Papyrus core'' <br />
If your feature is still in the incubation state you should add the following to your label: (Incubation)<br />
*Each feature must contain the Eclipse licence reference:<br />
<feature<br />
id="org.eclipse.papyrus.editor.feature"<br />
version="2.0.0.qualifier"<br />
label="%featureName"<br />
provider-name="%providerName" <br />
license-feature="org.eclipse.license"<br />
license-feature-version="2.0.2"><br />
<br />
<description url="https://eclipse.org/papyrus/"><br />
%description<br />
</description><br />
<br />
<copyright><br />
%copyright<br />
</copyright><br />
<br />
<license url="%licenseURL"><br />
%license<br />
</license> <br />
...<br />
</feature><br />
<br />
*The build.properties file must contain the following files in the "Binary build" section: <br />
**feature.properties which must contains:<br />
*** featureName<br />
*** providerName<br />
*** description<br />
*** copyright<br />
**feature.xml<br />
<br />
*The feature must only includes the repository's Papyrus plugins. If you need to make it depends on external plugins or features, be they from another Papyrus repository or any other repository, they should be added through the require of import mechanism. Refrain from using the include method as much as possible.<br />
<br />
=== Code Formatting ===<br />
Before writing any code you should check that you have the papyrus templates set as your format in your IDE.<br />
These can be [https://wiki.eclipse.org/Papyrus/Papyrus_Developer_Guide#Apply_Papyrus_Configuration_Files retrieved following these steps].<br />
<br />
These could also be retreived and applied from the .settings folder of each plugins. (An example can be found [https://git.eclipse.org/c/papyrus/org.eclipse.papyrus.git/tree/plugins/infra/core/org.eclipse.papyrus.infra.core.log/.settings here])<br />
<br />
=== Code Rules ===<br />
Before committing, you should verify these items&nbsp;: <br />
*'''copyright''' each file has an header with the EPL licence and your name <br />
* '''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.<br />
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.<br />
/*****************************************************************************<br />
* Copyright (c) 2015, 2018 CEA LIST, Committer Name, and others.<br />
*<br />
* All rights reserved. This program and the accompanying materials<br />
* are made available under the terms of the Eclipse Public License 2.0<br />
* which accompanies this distribution, and is available at<br />
* https://www.eclipse.org/legal/epl-2.0/<br />
*<br />
* SPDX-License-Identifier: EPL-2.0<br />
*<br />
* Contributors:<br />
* CEA LIST - Initial API and implementation<br />
* Committer Name (CEA LIST) committer.name@cea.fr - Bug 492522, Bug XXXXXX<br />
*****************************************************************************/<br />
<br />
###############################################################################<br />
# Copyright (c) 2013, 2018 CEA LIST, Committer Name, and others.<br />
#<br />
# All rights reserved. This program and the accompanying materials<br />
# are made available under the terms of the Eclipse Public License 2.0<br />
# which accompanies this distribution, and is available at<br />
# https://www.eclipse.org/legal/epl-2.0/<br />
#<br />
# SPDX-License-Identifier: EPL-2.0<br />
#<br />
# Contributors:<br />
#<br />
###############################################################################<br />
<br />
*'''default''' keyword in Interfaces: should be avoided and only used if unavoidable and justified (to prevent unnecessary API break for example)<br />
*'''var''' keyword is forbidden<br />
*'''lambda expressions''' are allowed, but must be commented to ease the understanding<br />
*'''externalized''' strings or tagged with //$NON-NLS-1$. 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 [https://wiki.eclipse.org/Papyrus/Papyrus_Developer_Guide/Externalize_Strings_In_Java link] for a guide on externalization in Eclipse.<br />
* '''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).<br />
* '''Naming''': No abbreviations - the class, methods and variables should have meaningful names.<br />
* '''Attributes''': All attributes, field must be at beginning of the class<br />
* '''Returns and conditions''': You can have as many 'return' statement you need in a method.<br />
* '''Javadoc''': It should exist for all methods (sometimes a simple @Inherited is enough). Automatic generation of JavaDoc comments may help, but the automatically generated comments are '''templates'''. They are not sufficient. It is better not to generate javadoc comments than to generate empty comments. <br />
* '''Tags''': (@since plugin-number, ...)<br />
/**<br />
* Constructs an Editor for multiple Integer values.<br />
* The widget is a List, with controls to move values up/down, add values and remove values.<br />
*<br />
* @param parent<br />
* The Composite in which this editor is created<br />
* @param directCreation<br />
* Indicates if the creation and modification are directed.<br />
* @param directCreationWithTreeViewer<br />
* Indicates if the creation and modification are directed on the TreeViewer.<br />
* @param style<br />
* The List's style<br />
*<br />
* @since 3.1<br />
*/<br />
public MultipleIntegerEditor(Composite parent, ...){}<br />
* '''Reexports''': A contributed code should never introduce any 'hidden' dependencies such as reexporting plugins dependencies.<br />
* '''Contribution''': A newly written code or plugin should always be added to the relevant poms and features.<br />
*'''versions numbers''' are correct. see [https://wiki.eclipse.org/Version_Numbering this guide] for more information.<br />
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/><br />
* all generated code shall be contained in the directory src-gen. Note that all code in this directory is not participant to the API.<br />
<br />
Here are some guidelines (which may be altered and/or improved) that every reviewer and committer should follow:<br />
<br />
===Logger===<br />
You must '''not''' use the standard console output in Papyrus plug-ins. Use the [https://wiki.eclipse.org/Papyrus/Papyrus_Developer_Guide/Papyrus_Log Papyrus log] instead.<br />
<br />
=== Plugin Versioning - Deprecated code ===<br />
Using the @Deprecated tag, you must do these things in the same time:<br />
*increase the minor version of the plugin (of course, only if it has not yet be done since the last release)<br />
**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.<br />
* indicate in the comment the plugin version when the class/method became deprecated<br />
* open a bug to remove the deprecated class/method in the next major release<br />
* reference this bug in the comment of the deprecated class/method<br />
* (optional) indicate in the comment in which major release the class/method will be remove<br />
<br />
Add the end, you must have something like that: <br />
<br />
<nowiki><br />
/**<br />
* @deprecated since 3.1<br />
* use {@link org.eclipse.papyrus.infra.gmfdiag.common.structure.DiagramStructure} API instead<br />
*<br />
* This class will be removed in Papyrus 5.0, see Bug 541027<br />
*/<br />
@Deprecated<br />
public abstract class DiagramStructure {<br />
...<br />
}<br />
</nowiki><br />
<br />
=== Automatic check ===<br />
<br />
Most of these rules are checked automatically when running the Papyrus tests. If you want to check them locally, use the plug-in ''org.eclipse.papyrus.bundles.tests'' (''Run as &gt; Junit plug-in test'' or use the ''*.launch'' file from this plug-in). This plug-in can be retrieved on the Papyrus Git repository: [https://git.eclipse.org/c/papyrus/org.eclipse.papyrus.git/tree/tests/junit/framework/org.eclipse.papyrus.bundles.tests org.eclipse.papyrus.bundles.tests].<br />
<br />
=== API ===<br />
* Code of plugins shall be inside internal package<br />
* API shall be public and each classe presence shall be justified by implementation of usecase<br />
* The usecase are store inside the plugin the name of the file '''XXX.usecases.md'''<br />
* The grammar is:<br />
### requirement text <br />
* qualified name of the class<br />
<br />
* See the following example<br />
<br />
### The profile validation must be done with a button 'Validate Profile plug-in' on plug-in, in the papyrus developer menu<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.handlers.ValidateProfilePluginHandler<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.testers.ValidateProfilePluginTester<br />
* plugin.xml<br />
### During the validation, a progress monitor must be opened with correct explanations<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.handlers.ValidateProfilePluginHandler<br />
### A checker for the extensions must be implemented<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.internal.checkers.ProfileExtensionsChecker<br />
### A checker for the definition profile must be implemented<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.internal.checkers.ProfileDefinitionChecker<br />
<br />
== Write Documentation for Papyrus ==<br />
Each new contribution must contribute to the documentation (behavior changes or new feature). <br />
The documentation must be splitted in two parts: <br />
*user documentation<br />
*developer documentation<br />
<br />
How to - Related to documentation [[Papyrus Developer Guide/Writing Documentation]]<br />
<br />
== Contribute ==<br />
<br />
===ECA===<br />
The developer should have signed the [https://www.eclipse.org/legal/ECA.php Eclipse Contributor Agreement]<br />
If the writer is an employee and his company has signed a Member Committer Agreement&nbsp;: after the commit, you should comment the attachment writing&nbsp;: <br />
*Here is a contribution from one employee of "the name of the company" <br />
*The company has signed a Member Committer Agreement. <br />
*The contribution does not need a CQ. <br />
*I've committed this contribution. <br />
*Committed revision xxx. <br />
*Set the field iplog to +<br />
<br />
Note&nbsp;: In reality, you should have the authorization of the PMC before doing this commit.<br />
<br />
=== CQs ===<br />
Remember to check on the current CQs to see if they are still current and that we will not miss any currently required dependencies (e.g. glazed lists in the new orbit or the new apache.common.io dependency) as well as the IPlogs. A quick tutorial on CQs can be found [https://wiki.eclipse.org/Papyrus_Developer_Guide/Contribution_Questionaire here].<br />
<br />
If you have any doubt about your contribution you can always check this [https://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf Eclipse chart] for more information.<br />
<br />
=== Gerrit ===<br />
<br />
If you want to contribute code, and you are not a committer, here is how to proceed:<br />
<br />
When a non-committer wants to contribute to Papyrus, he must create patchs and attach them to a bug using the Bug number in the message (e.g. commit -m "Bug 561154 - xyz"), this will automatically contribute the patch to the Bugzilla ticket. In the comment of each patch, he must write&nbsp;: <br />
<br />
* I, Forename Name, wrote 100% of the code I've provided. <br />
* This code contains no cryptography <br />
* I have the right to contribute the code to Eclipse. <br />
* I contribute the content under the EPL 2.0.<br />
<br />
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.<br />
<br />
== Code Reviews ==<br />
The reviewer shall verify that the contribution respects all [https://wiki.eclipse.org/Papyrus/Papyrus_Developer_Guide/How_To-_Code_Contributing#Code_Rules aforementioned rules].<br />
<br />
== Merge ==<br />
Eclipse release calendar is detailled [[Simultaneous_Release|here]]. Each date of releases (M1, M2, M3, RC1, RC2 and GA) for the new Eclipse version is defined in a associated wiki page of the Eclipse version). <br />
<br />
Contributions should be merged before:<br />
*M2+<br />
It is forbidden to modify the GUI. Only important bug fixes should be merged. <br />
Creation of a branch (tag) for the release<br />
*M3+<br />
It is forbidden to modify the features and general architecture.<br />
*RC1+<br />
Its forbidden to merge contribution. Only by the project Chief for critical bugs.<br />
<br />
[[Category:Papyrus]]</div>Patrick.Tessier.cea.frhttps://wiki.eclipse.org/index.php?title=Papyrus/Papyrus_Developer_Guide/How_to_Contribute_to_Papyrus_with_Gerrit&diff=440996Papyrus/Papyrus Developer Guide/How to Contribute to Papyrus with Gerrit2020-09-28T09:08:27Z<p>Patrick.Tessier.cea.fr: /* How to commit using EGit */</p>
<hr />
<div>Using Gerrit, you can contribute to the Papryrus project, even if you aren't a committer. <br />
If you have not cloned the repository yet please follow the tutorial available [[Papyrus Developer Guide/Papyrus Git Tutorial | here]].<br />
<br />
<br />
<br />
=== Sign in the eclipse development chart ===<br />
<br />
*Create an Eclipse Bugzilla account : https://dev.eclipse.org/site_login/createaccount.php<br />
This step is your average account creation, and it will require you to visit a mail sent URL to validate the account.<br />
*Sign the CLA : https://wiki.eclipse.org/CLA<br />
This can be done ( by visitiing the following link: https://projects.eclipse.org/user/login/sso ) once logged in by clicking on Contributor License Agreement and following all the instruction on this same page.<br />
*Activate your Gerrit account : https://git.eclipse.org/r/<br />
The id and password , just as your sign-in information on the eclipse website, are the mail address you used to create the eclipse account and the associated password, no need to create a new one.<br />
*And Add your ssh key, if you have one, to your gerrit account by going into your settings and then <b>SSH Public Keys>Add Key</b> and paste the newly generated public key. It should look like: <b>[algorithm] [key] [comment]</b>, as shown here the first one is of the form: <b>ssh-rsa xxxxxxxxx Generated</b><br />
<br />
[[File:EGit_ssh2.png|1000px]]<br />
<br />
<br /><br /><br />
<br />
=== Configure push for Gerrit ===<br />
<br />
Because you're not an official Papyrus commiter, you can't just commit your code on the papyrus git repository; you have to submit your contribution via the commit refs/for/master branch. <br />
<br />
<br />
==== Via EGit ====<br />
You can configure EGit for push on that particular branch:<br />
<br />
* On the Git Repositories view, open ''Remotes''<br />
* Add a new Remote by right clicking on ''Remotes'', then choose ''Create Remote...'', and choose a new name (for example Gerrit) <br />
N.B. : you can also choose to modify the origin remote.<br />
* Configure Gerrit for this remote by right clicking on it, and Gerrit Configuration<br />
<br />
You now have to configure the repository URI :<br />
* Choose your preferred protocole (http, https, ssh)<br />
* Enter the papyrus URI : <br />
** via ssh : '''ssh://[committer_id]@git.eclipse.org:29418/papyrus/org.eclipse.papyrus''', where [commiter_id] is your Gerrit id.<br />
** via https : '''https://[committer_id]@git.eclipse.org/r/papyrus/org.eclipse.papyrus'''<br />
<br />
[[File:EGit_PushConfigurations.png | 800px]]<br />
<br />
<br /><br /><br />
<br />
* The above push configurations already contain your Gerrit id in the adress, and therefore the Gerrit id field will be updated automatically in the configuration window.<br />
* You may want to enter you password so that you won't have to type it on each push.<br />
<br />
If you're experiencing problems, please verify that you're pushing on refs/for/master (Or refs/drafts/master for hidden review)<br />
<br />
<br /><br />
<br />
==== Via command line ====<br />
git remote add sshGerrit ssh://[[committer_id]]@git.eclipse.org:29418/papyrus/org.eclipse.papyrus<br />
<br />
Before commit somethings for papyrus do not forget to configure your git with<br />
<br />
core.autocrlf = input<br />
<br />
=== How to commit using EGit ===<br />
<br />
A good way to do this is to open the Git perspective inside your eclipse window as it will have all the necessary views to achieve what you want to do in this case.<br />
The first step is to verify that your local branches have a remote assigned and that it is the remote you want to push on, as the mechanism of commit and push of egit will select this one by default. This can be done easily by clicking on the branch in your Git repository interface and selecting the "Configure Branch" option.<br />
<br />
[[File:EGit_Branch_Configuration0.png | 600px]]<br />
<br />
Or by editing the <b>Preferences>Team>Git>Configuration</b> "Repository Settings" and defining which default remote your branch will be attached to.<br />
<br />
[[File:EGit_Branch_Configuration2.png | 1000px]]<br />
<br />
<br /><br /><br />
<br />
Once this is done you will have to create, or amend, the commit by going to the "Git Staging" tab. there you will have all the changes detected by EGit (it might be a little messy and full of files you didn't even touch, as is the case in this image, but don't pay it attention as your changes will be there as well) and drag the wanted files from <b> Unstaged Changes </b> to <b> Staged Changes </b>. then edit the commit message:<br />
* The first line of your commit comment should be the bugzilla task number and its name; example : Bug 12345 - The name of the bug you fixed.<br />
* Then should be the fixes you provided<br />
* If it is an amend of a precedent commit be sure to add the Change-Id provided by gerrit (upper left corner of the gerrit page) and separate the Change-Id from the rest of the meassage with a blank line<br />
* You will then have to sign-off your commit <br />
<br />
[[File:EGit_Staging1.png | 1000px]]<br />
<br />
[[File:EGit_Staging2.png | 1000px]]<br />
<br />
If you only need to amend a commit EGit provides a fast way to edit the message with the "amend previous commit", "add signed off by" and "add Change Id" buttons. You can then pr<br />
<br />
[[File:EGit_Staging0.png | 1000px]]<br />
<br />
<br /><br /><br />
<br />
The first commit on a Bug won't have a change-id as this will be created when the commit is pushed and accepted by Gerrit. The change-id can be retrieved by visiting the pushed commit on Gerrit.<br />
With EGit the "amend previous commit" button should fill the new commit's message with the previous fields. It is important to know that the Change-Id must be separated from the commit message by a blank line, so that it will be identified from the rest of the message and your push to gerrit will update the existing one.<br />
<br />
==== Once the commit is submitted ====<br />
<br />
Once all this is done, don't forget to link the gerrit page inside a comment in the related Bugzilla page. This little update will make things easier for the users and even serve you as a reminder to close or update the Bugzilla status ! <br />
<br />
Gerrit & Bugzilla are now synchronized. A reference from Bugzilla to the Gerrit contribution is now automatically added as soon as the contribution is proposed, and another comment is added when the contribution is accepted (merged). Note that this synchronization can only happen if the Contribution contains the Bug ID in the commit message (‘<b>Bug 123456</b>: ....’). Also note that by default, Mylyn/Bugzilla only writes the bug number (Without the ‘Bug’ prefix), which doesn’t trigger the automatic synchronization.<br />
<br />
<br /><br />
<br />
=== How to commit using commands ===<br />
<br />
The editor used in this section is Cygwin ( https://www.cygwin.com/ ), to which we added the specific git packages: git-completion, gui, svn and fast version control system. To install them choose a site, such as mirrors.kernel.org<br />
To make the display more comfortable and easier to read, it is preferable to run the following command: <b> git config --global color.ui true </b>, if it is not already enabled, so that you will have access to all the nice colors. Also, if you are allergic to VI, try installing another editor, like nano.<br />
<br />
<br /><br />
==== Install the commit-hook in your local repository ====<br />
<br />
This hook will automaticaly insert ''Gerrit Change-Id'' in your commit message<br />
scp -p -P 29418 username@git.eclipse.org:hooks/commit-msg .git/hooks/<br />
see also [[EGit/Contributor_Guide#Install_the_commit-msg_hook_in_your_repository|Install the commit-msg hook in your repository]]<br />
<br />
<br />
==== First push - How to commit and push ====<br />
<br />
[[File:first_Commit.png | 1000px]]<br />
<br />
Having created an empty file (using the touch command) inside the git repository, git sees it as a modification and therefore the <b> git status </b> command shows the file as untracked. <br />
We add it to the index of the next commit using <b> git add [file name] </b> and as you can see by the second <b> git status </b> the file testGerrit.txt is in the "Changes to be committed".<br />
The next step is to create the commit itself. For this purpose we run the <b> git commit -m "[your commit message]" --signoff </b> command. This command decompose itself in 3:<br />
* The actual order of commit, by using the commit keyword<br />
* The message we want to asociate with the commit, by using -m an entering the commit message between comas<br />
* The addition of the signature without which your commit will be refused, by adding --signoff (or just -s). This signature is comprised of your previously defined user name and user email.<br />
<br />
Before pushing on gerrit it is preferable to update your local branch from the remote as that should prevent merge conflicts if your change is accepted and merged. <br />
* To do this we used the <b> git fetch </b> ( short for: git fetch [name of the git remote], and in this example the remote of the repository is named "origin" ) that will import all the changes (commits) that happened since the last update of the branch or, if no update were done, since the creation of the branch.<br />
* And <b> git rebase </b> ( short for: git rebase [name of the remote branch], which in this case is "origin/master" ) that will detach all the work done on the local branch, patch the local branch with the changes that happened on the remote branch and replay the work on top of them, effectively giving you an updated branch and clean base to push your new commit.<br />
<br />
[[File:fetch&rebase.png | 600px]]<br />
<br />
<br /><br /><br />
<br />
Then, we push the commit onto Gerrit. It will signal you if the build incorporating your changes has failed and allow your code to be reviewed before being merged. Instead of pushing to the actual branch, your local is based on, Gerrit uses "magic branches", effectively virtual branches, for the purpose of reviewing the code and pushing it, or not depending on the review, on the actual git remote. Those are identified with the "refs/for/[remote]" tag.<br />
<br />
[[File:Gerrit_Magic_Branches.png | 600px]]<br />
<br />
[[File:first_Push_Https.png | 1000px]]<br />
<br />
<br /><br /><br />
<br />
You will be able to see your contribution by opening Gerrit's web interface ( https://git.eclipse.org/r ). Filters can be applied in the search fieldbox. Useful ones in this case are:<br />
* status:open, that will only show the opened and not yet reviewed commits<br />
* project:papyrus/org.eclipse.papyrus, that will only show commit related to the papyrus project<br />
<br />
And this is what your commit details will look like:<br />
<br />
[[File:first_Push_Result.png | 1000px]]<br />
<br />
<br /><br />
<br />
==== Second push - What not to do, or not too often ====<br />
<br />
Please keep in mind that, for the following steps ("second push" and "third push"), we are in the Gerrit situation where the contribution has not yet been merged. Amended commits are actually entirely new commits, and the previous commit is removed from the project history. If you amend a commit that other developers have based their work on it will look like the basis of their work has vanished from the project history and that is a tricky situation to recover from. <br />
<br />
Now lets say that you want to add modifications to the project you are working on. In this case we just create a new file "testGerritMod.txt". As a newly created file, a "git status" tells us that it is added to the untracked list, that is the not yet committed files. We add the new file to the index and create a new commit as usual and adding the Change-Id to our message in order to signify gerrit that it is a modification of our first commit. As a reminder, remember to put an empty line between the commit message and the footer containing the Change-Id.<br />
<br />
[[File:second_Commit.png | 1000px]]<br />
<br />
<br /><br /><br />
<br />
But the problem is that we did not amend the first commit but created a new and different commit altogether without deleting the first one. Therefore we try to have two commits with the same Change-Id and that is just not possible. The push order gets rejected. Time for a squash, that is a rebase -i, of our two commits: <b> git rebase -i HEAD~2 </b> which means that we get the last two commits (~2) done from our local branch (HEAD).<br />
We then get an editor in which we choose how to fuse the commits together (image pending) and, once this is done, another that allows us to edit and choose which commit message to use.<br />
<br />
[[File:squash_For_Second_Push.png | 1000px]]<br />
<br />
[[File:squash_Commits_Message1.png | 1000px]]<br />
<br />
[[File:squash_Commits_Message2.png | 1000px]]<br />
<br />
<br /><br /><br />
<br />
As we can see the updated gerrit contribution contains the new file and the updated commit message.<br />
<br />
[[File:second_Push_Result.png | 1000px]]<br />
<br />
<br /><br />
<br />
==== Third push - How to do it correctly ====<br />
<br />
To amend a commit properly you just have to run the <b> git commit --amend </b> that will allow you to amend the last commit done on this branch. In this case we create a new file to our test, add it to the index and then run the command. The new file is added to the commit and a message editor is opened to allow us to modify the commit message if need be. After making sure that our branch is still up to date, we push the new modification on gerrit (this time by ssh just to show that you can manipulate both together).<br />
<br />
[[File:third_Commit_Amend.png | 1000px]]<br />
<br />
[[File:third_Commit_Message_Amend1.png | 1000px]]<br />
<br />
[[File:third_Commit_Message_Amend2.png | 1000px]]<br />
<br />
<br /><br /><br />
<br />
Now that all is up to speed we can push the new modifications.<br />
<br />
[[File:third_Push_SSH.png | 1000px]]<br />
<br />
<br /><br /><br />
<br />
And the resulting modifications on the Gerrit page.<br />
<br />
[[File:third_Push_Result.png | 1000px]]<br />
<br />
<br /><br /><br />
<br />
=== Useful Tips ===<br />
<br />
==== Git Commands ====<br />
<br />
Here is a list a commands you may find useful:<br />
* <b>git status</b>: allows you to see which files were changed in your repository<br />
* <b>git add -i</b>: opens an interface that allows you to choose which files to add in bulk<br />
* <b>git stash</b>: if you have unstaged changes in your local repository you wont be able to rebase after a fetch, or you will loose them if you switch branches. The stash command pu those changes away to be retrieved later. A new folder "Stashed Commits" will be created and your unstaged changes put in the Stash@{0} folder. It is useful to know that each new stash will take the Stash@{0} name and increment the anterior ones index by 1 ( Stash@{1}, ... )<br />
* <b>git stash list</b>: will list all the stash you have in store<br />
* <b>git branch</b>: will list all the branches created in your local git and notify you where you are<br />
* <b>git branch -vv</b>: will show you all your branches and the remote they are based on<br />
* <b>git log -n</b>: will display the last "n" commits that happened in your branch<br />
* <b>git log -n --pretty=oneline</b>: just as above but will show each one on a single line, useful if you want to display a lot of them<br />
* <b>git reset --soft HEAD~n</b>: rewind the last "n" actions done on your branch. Only use this to correct your own mistakes as it can lead to annoying situations<br />
* <b>git reset --hard [remote]</b>: resets the local branch to look like the remote. Again be careful as any changes on your end will be erased <br />
<br />
As a reminder here are some Git related commands, just in case:<br />
* <b>git clone [remote uri] [local path]</b>: clone the git repository at the uri address mentioned<br />
* <b>git remote add [name] [remote uri]</b>: add a new remote<br />
* <b>git checkout [name of the local branch]</b>: switch to the mentioned branch<br />
* <b>git checkout -b [name of the local branch] [remote uri]</b>: create a new local branch from the remote<br />
* <b>git branch --set-upstream [name of the remote]</b>: will set the new remote as the upstream for this branch<br />
<br />
Of course, don"t forget the very useful command:<br />
* <b>man git</b>: allows you to access all the possible commands with a brief explanation of their purpose<br />
<br />
<br /><br />
<br />
==== VI Commands ====<br />
And if you use the VI editor:<br />
There are two "modes", one for editing (inserting) and one for navigating through the file, that we will call "I mode" and "Esc mode" respectively. Each of them are entered by pressing the associated key and exited by pressing its counterpart.<br />
* <b>i</b> (I mode): allows you to edit a line. Be aware that the text will be inserted before the cursor<br />
* <b>dd</b> (Esc mode): allows you to delete a line<br />
* <b>x</b> (Esc mode): delete a character<br />
* <b>o</b> (Esc mode): insert blank line<br />
* <b>u</b> (Esc mode): undo last changes<br />
<br />
* <b>:w</b> (Esc mode): saves the changes in the file<br />
* <b>:wq</b> (Esc mode): saves the changes and exits the editor<br />
* <b>:q!</b> (Esc mode): exits the editor without saving anything<br />
<br />
<br /><br />
<br />
More information of how to use git on [https://wiki.eclipse.org/Development_Resources/Contributing_via_Git Contributing via Git]<br />
<br />
<br />
==== Mylyn Configuration ====<br />
Here is a basic example of how to configure mylyn to receive the bugs associated withe Papyrus:<br />
First, after installing the mylyn connector just as you would any other new software (Help>Install New Software), open the mylyn view (Window>Show View). From there select the <b>New Query</b> option and proceed as illustrated below.<br />
<br />
[[File:mylyn_Config1.png | 600px]]<br />
<br />
[[File:mylyn_Config2.png | 600px]]<br />
<br />
[[File:mylyn_Config3.png | 600px]]<br />
<br />
<br />
As a side note you can file bugs directly from mylyn using the <b>New Task</b> option from the Task Repositories view. Then, proceed to fill the requiered fields corresponding to your use case and submit the newly created bug.<br />
<br />
[[File:mylyn_Bug1.png | 600px]]<br />
<br />
[[File:mylyn_Bug2.png | 600px]]<br />
<br />
[[File:mylyn_Bug3.png | 600px]]</div>Patrick.Tessier.cea.frhttps://wiki.eclipse.org/index.php?title=Papyrus/Papyrus_Developer_Guide/How_To-_Code_Contributing&diff=440636Papyrus/Papyrus Developer Guide/How To- Code Contributing2020-09-10T15:14:35Z<p>Patrick.Tessier.cea.fr: /* Contribute */</p>
<hr />
<div>__TOC__<br />
<br />
<br />
All papyrus contributors shall follow these rules:<br />
<br />
== Write a Bugzilla task ==<br />
When adding a task to the buzilla, the following grammar should be used: <br />
<br />
*'[' ''Category'' ']' ''NameOfTheTask''<br><br />
<br />
The category helps to filter the bugs for developers. There are already some existing categories: General, XXX Diagram, Common, Property View, etc.<br />
<br />
As a reminder, the lifecycle of bugs is located here: [[Development Resources/HOWTO/Bugzilla Use|Bugzilla Use]]<br />
<br />
*Your contribution shall be associated to a bug refenced in the bugzilla.<br />
*When a bug is opened/resolved/closed the Target Milestone must be filled. For example the bug has been fixed for the service release 3 of oxygen, the target milestone is 3.3.<br />
<br />
<br />
== Write the code ==<br />
<br />
=== Papyrus Plugin Structure ===<br />
<br />
*Papyrus plugin naming scheme and folder structure used to locate and name plugins is described here: [[Papyrus/Papyrus_Developer_Guide/Papyrus_Plugin_Naming_Scheme]]<br />
<br />
*All plug-ins must compile and run against JavaSE-1.8. Papyrus 5.0 must compile against openjdk-11.<br />
*Plug-in provider&nbsp;: ''Eclipse Modeling Project'' <br />
*Version&nbsp;: <br />
***Papyrus adheres to the [[Version Numbering|Eclipse Versioning Guidelines]] for API evolution and other kinds of changes''<br />
*Plug-in name&nbsp;: must end with (Incubation) if version is less than 1.0.0 . If the version is at least 1.0.0, the (Incubation) suffix must be removed.<br />
*Plug-in ID&nbsp;: must start with org.eclipse.papyrus.<br />
*Plug-in dependencies must not be re-exported.<br />
*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"'')<br />
**The Papyrus Developer Tools has 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<br />
*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: <br />
**META-INF/ <br />
**about.html <br />
**icons/, images/, resources/, models/, etc. (All folders containing runtime resources) <br />
**plugin.properties <br />
**plugin.xml <br />
**schema/ <br />
*Do '''not''' include the following files: <br />
**.classpath <br />
**.project <br />
**bin/, src/, src-gen/, custom-src/ <br />
**build.properties <br />
*The ''Source build'' (field src.includes in build.properties) category '''must''' contain the '''about.html''' file: <br />
*It '''must not''' contain the following: <br />
**src/, src-gen/, custom-src/ <br />
**All files and directories are already contained in the "Binary build" category (Except the about.html which must be contained in both Binary and Source builds)<br />
<br />
plugin.xml:<br><br />
[[Image:Papyrus.codestandards.plugin.xml.png]]<br />
<br />
<br />
=== Code Formatting ===<br />
Before writing any code you should check that you have the papyrus templates set as your format in your IDE.<br />
These can be [https://wiki.eclipse.org/Papyrus/Papyrus_Developer_Guide#Apply_Papyrus_Configuration_Files retrieved following these steps].<br />
<br />
These could also be retreived and applied from the .settings folder of each plugins. (An example can be found [https://git.eclipse.org/c/papyrus/org.eclipse.papyrus.git/tree/plugins/infra/core/org.eclipse.papyrus.infra.core.log/.settings here])<br />
<br />
=== Code Rules ===<br />
Before committing, you should verify these items&nbsp;: <br />
*'''default''' keyword in Interfaces: should be avoided and only used if unavoidable and justified (to prevent unnecessary API break for example)<br />
*'''var''' keyword is forbidden<br />
*'''lambda expressions''' are allowed, but must be commented to ease the understanding<br />
*each file has an header with the EPL licence and your name <br />
*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.<br />
*the version numbers are correct. see [https://wiki.eclipse.org/Version_Numbering this guide] for more information.<br />
<br />
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/><br />
Here are some guidelines (which may be altered and/or improved) that every reviewer and committer should follow:<br />
* '''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.<br />
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.<br />
/*****************************************************************************<br />
* Copyright (c) 2015, 2018 CEA LIST, Committer Name, and others.<br />
*<br />
* All rights reserved. This program and the accompanying materials<br />
* are made available under the terms of the Eclipse Public License 2.0<br />
* which accompanies this distribution, and is available at<br />
* https://www.eclipse.org/legal/epl-2.0/<br />
*<br />
* SPDX-License-Identifier: EPL-2.0<br />
*<br />
* Contributors:<br />
* CEA LIST - Initial API and implementation<br />
* Committer Name (CEA LIST) committer.name@cea.fr - Bug 492522, Bug XXXXXX<br />
*****************************************************************************/<br />
<br />
###############################################################################<br />
# Copyright (c) 2013, 2018 CEA LIST, Committer Name, and others.<br />
#<br />
# All rights reserved. This program and the accompanying materials<br />
# are made available under the terms of the Eclipse Public License 2.0<br />
# which accompanies this distribution, and is available at<br />
# https://www.eclipse.org/legal/epl-2.0/<br />
#<br />
# SPDX-License-Identifier: EPL-2.0<br />
#<br />
# Contributors:<br />
#<br />
###############################################################################<br />
<br />
* '''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.<br />
* '''Strings''': Verify the Non-NLS markers.<br />
* '''Tags''': (@since plugin-number, ...)<br />
/**<br />
* Constructs an Editor for multiple Integer values.<br />
* The widget is a List, with controls to move values up/down, add values and remove values.<br />
*<br />
* @param parent<br />
* The Composite in which this editor is created<br />
* @param directCreation<br />
* Indicates if the creation and modification are directed.<br />
* @param directCreationWithTreeViewer<br />
* Indicates if the creation and modification are directed on the TreeViewer.<br />
* @param style<br />
* The List's style<br />
*<br />
* @since 3.1<br />
*/<br />
public MultipleIntegerEditor(Composite parent, ...){}<br />
<br />
* '''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.<br />
* '''Reexports''': A contributed code should never introduce any 'hidden' dependencies such as reexporting plugins dependencies.<br />
* '''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).<br />
* '''Attributes''': All attributes, field must be at beginning of the class<br />
* '''Returns and conditions''': You can have as many 'return' statement you need in a method.<br />
<br />
* '''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.<br />
<feature <br />
id="org.eclipse.papyrus.XXXXXXX.feature" <br />
version="2.0.0.qualifier"<br />
label="%featureName" <br />
provider-name="%providerName" <br />
license-feature="org.eclipse.license"<br />
license-feature-version="2.0.0"><br />
<br />
<description><br />
%description<br />
</description><br />
<br />
<copyright><br />
%copyright<br />
</copyright><br />
<br />
<license url="%licenseURL"><br />
%license<br />
</license><br />
<br />
<br />
==== String Externalization/Internalization ====<br />
*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,<br />
<br />
Follow this [[Papyrus_Developer_Guide/Externalize_Strings_In_Java | link]] for a guide on externalization in Eclipse.<br />
<br />
=== Write Documentation for Papyrus ===<br />
Each new contribution must contribute to the documentation (behavior changes or new feature). <br />
The documentation must be splitted in two parts: <br />
*user documentation<br />
*developer documentation<br />
<br />
How to - Related to documentation [[Papyrus Developer Guide/Writing Documentation]]<br />
<br />
=== Plugin Versioning - Deprecated code ===<br />
Using the @Deprecated tag, you must do these things in the same time:<br />
*increase the minor version of the plugin (of course, only if it has not yet be done since the last release)<br />
**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.<br />
* indicate in the comment the plugin version when the class/method became deprecated<br />
* open a bug to remove the deprecated class/method in the next major release<br />
* reference this bug in the comment of the deprecated class/method<br />
* (optional) indicate in the comment in which major release the class/method will be remove<br />
<br />
Add the end, you must have something like that: <br />
<br />
<nowiki><br />
/**<br />
*<br />
* @deprecated since 3.1<br />
* use {@link org.eclipse.papyrus.infra.gmfdiag.common.structure.DiagramStructure} API instead<br />
*<br />
* This class will be removed in Papyrus 5.0, see Bug 541027<br />
*<br />
*<br />
*/<br />
@Deprecated<br />
public abstract class DiagramStructure {<br />
...<br />
}<br />
</nowiki><br />
<br />
=== API ===<br />
* Code of plugins shall be inside internal package<br />
* API shall be public and each classe presence shall be justified by implementation of usecase<br />
* The usecase are store inside the plugin the name of the file '''XXX.usecases.md'''<br />
* The grammar is:<br />
### requirement text <br />
* qualified name of the class<br />
<br />
* See the folowing example<br />
<br />
### The profile validation must be done with a button 'Validate Profile plug-in' on plug-in, in the papyrus developer menu<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.handlers.ValidateProfilePluginHandler<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.testers.ValidateProfilePluginTester<br />
* plugin.xml<br />
### During the validation, a progress monitor must be opened with correct explanations<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.handlers.ValidateProfilePluginHandler<br />
### A checker for the extensions must be implemented<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.internal.checkers.ProfileExtensionsChecker<br />
### A checker for the definition profile must be implemented<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.internal.checkers.ProfileDefinitionChecker<br />
<br />
== Contribute ==<br />
<br />
===ECA===<br />
The developer should have signed the [https://www.eclipse.org/legal/ECA.php Eclipse Contributor Agreement]<br />
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;: <br />
*Here is a contribution from one employee of "the name of the company" <br />
*The company has signed a Member Commiter Agreement. <br />
*The contribution does not need a CQ. <br />
*I've committed this contribution. <br />
*Committed revision xxx. <br />
*Set the field iplog to +<br />
<br />
Note&nbsp;: In reality, you should have the autorization of the PMC before doing this commit. <br />
<br />
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.<br />
<br />
In all other cases, see http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf<br />
<br />
=== CQs ===<br />
Remember to check on the current CQs to see if they are still current and that we will not miss any currently required dependencies (e.g. glazed lists in the new orbit or the new apache.common.io dependency) as well as the IPlogs. A quick tutorial on CQs can be found [https://wiki.eclipse.org/Papyrus_Developer_Guide/Contribution_Questionaire here].<br />
<br />
=== Gerrit ===<br />
<br />
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]]<br />
<br />
(For further information, see http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf) <br />
<br />
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;: <br />
<br />
* I, Forename Name, wrote 100% of the code I've provided. <br />
* This code contains no cryptography <br />
* I have the right to contribute the code to Eclipse. <br />
* I contribute the content under the EPL.<br />
<br />
+ Set the field Review to '?'.<br />
<br />
=== Commit message ===<br />
*During the commit&nbsp;: <br />
**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.<br />
<br />
== Code Reviews ==<br />
The reviewer shall verify that the contribution respects all [https://wiki.eclipse.org/Papyrus/Papyrus_Developer_Guide/How_To-_Code_Contributing#Code_Rules aforementioned rules].<br />
<br />
== Merge ==<br />
Eclipse release calendar is detailled [[Simultaneous_Release|here]]. Each date of releases (M1, M2, M3, RC1, RC2 and GA) for the new Eclipse version is defined in a associated wiki page of the Eclipse version). <br />
<br />
Contributions should be merged before:<br />
*M2+<br />
It is forbidden to modify the GUI. Only important bug fixes should be merged. <br />
Creation of a branch (tag) for the release<br />
*M3+<br />
It is forbidden to modify the features and general architecture.<br />
*RC1+<br />
Its forbidden to merge contribution. Only by the project Chief for critical bugs.</div>Patrick.Tessier.cea.frhttps://wiki.eclipse.org/index.php?title=Papyrus/Papyrus_Developer_Guide/How_To-_Code_Contributing&diff=440635Papyrus/Papyrus Developer Guide/How To- Code Contributing2020-09-10T15:09:15Z<p>Patrick.Tessier.cea.fr: /* Code Rules */</p>
<hr />
<div>__TOC__<br />
<br />
<br />
All papyrus contributors shall follow these rules:<br />
<br />
== Write a Bugzilla task ==<br />
When adding a task to the buzilla, the following grammar should be used: <br />
<br />
*'[' ''Category'' ']' ''NameOfTheTask''<br><br />
<br />
The category helps to filter the bugs for developers. There are already some existing categories: General, XXX Diagram, Common, Property View, etc.<br />
<br />
As a reminder, the lifecycle of bugs is located here: [[Development Resources/HOWTO/Bugzilla Use|Bugzilla Use]]<br />
<br />
*Your contribution shall be associated to a bug refenced in the bugzilla.<br />
*When a bug is opened/resolved/closed the Target Milestone must be filled. For example the bug has been fixed for the service release 3 of oxygen, the target milestone is 3.3.<br />
<br />
<br />
== Write the code ==<br />
<br />
=== Papyrus Plugin Structure ===<br />
<br />
*Papyrus plugin naming scheme and folder structure used to locate and name plugins is described here: [[Papyrus/Papyrus_Developer_Guide/Papyrus_Plugin_Naming_Scheme]]<br />
<br />
*All plug-ins must compile and run against JavaSE-1.8. Papyrus 5.0 must compile against openjdk-11.<br />
*Plug-in provider&nbsp;: ''Eclipse Modeling Project'' <br />
*Version&nbsp;: <br />
***Papyrus adheres to the [[Version Numbering|Eclipse Versioning Guidelines]] for API evolution and other kinds of changes''<br />
*Plug-in name&nbsp;: must end with (Incubation) if version is less than 1.0.0 . If the version is at least 1.0.0, the (Incubation) suffix must be removed.<br />
*Plug-in ID&nbsp;: must start with org.eclipse.papyrus.<br />
*Plug-in dependencies must not be re-exported.<br />
*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"'')<br />
**The Papyrus Developer Tools has 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<br />
*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: <br />
**META-INF/ <br />
**about.html <br />
**icons/, images/, resources/, models/, etc. (All folders containing runtime resources) <br />
**plugin.properties <br />
**plugin.xml <br />
**schema/ <br />
*Do '''not''' include the following files: <br />
**.classpath <br />
**.project <br />
**bin/, src/, src-gen/, custom-src/ <br />
**build.properties <br />
*The ''Source build'' (field src.includes in build.properties) category '''must''' contain the '''about.html''' file: <br />
*It '''must not''' contain the following: <br />
**src/, src-gen/, custom-src/ <br />
**All files and directories are already contained in the "Binary build" category (Except the about.html which must be contained in both Binary and Source builds)<br />
<br />
plugin.xml:<br><br />
[[Image:Papyrus.codestandards.plugin.xml.png]]<br />
<br />
<br />
=== Code Formatting ===<br />
Before writing any code you should check that you have the papyrus templates set as your format in your IDE.<br />
These can be [https://wiki.eclipse.org/Papyrus/Papyrus_Developer_Guide#Apply_Papyrus_Configuration_Files retrieved following these steps].<br />
<br />
These could also be retreived and applied from the .settings folder of each plugins. (An example can be found [https://git.eclipse.org/c/papyrus/org.eclipse.papyrus.git/tree/plugins/infra/core/org.eclipse.papyrus.infra.core.log/.settings here])<br />
<br />
=== Code Rules ===<br />
Before committing, you should verify these items&nbsp;: <br />
*'''default''' keyword in Interfaces: should be avoided and only used if unavoidable and justified (to prevent unnecessary API break for example)<br />
*'''var''' keyword is forbidden<br />
*'''lambda expressions''' are allowed, but must be commented to ease the understanding<br />
*each file has an header with the EPL licence and your name <br />
*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.<br />
*the version numbers are correct. see [https://wiki.eclipse.org/Version_Numbering this guide] for more information.<br />
<br />
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/><br />
Here are some guidelines (which may be altered and/or improved) that every reviewer and committer should follow:<br />
* '''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.<br />
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.<br />
/*****************************************************************************<br />
* Copyright (c) 2015, 2018 CEA LIST, Committer Name, and others.<br />
*<br />
* All rights reserved. This program and the accompanying materials<br />
* are made available under the terms of the Eclipse Public License 2.0<br />
* which accompanies this distribution, and is available at<br />
* https://www.eclipse.org/legal/epl-2.0/<br />
*<br />
* SPDX-License-Identifier: EPL-2.0<br />
*<br />
* Contributors:<br />
* CEA LIST - Initial API and implementation<br />
* Committer Name (CEA LIST) committer.name@cea.fr - Bug 492522, Bug XXXXXX<br />
*****************************************************************************/<br />
<br />
###############################################################################<br />
# Copyright (c) 2013, 2018 CEA LIST, Committer Name, and others.<br />
#<br />
# All rights reserved. This program and the accompanying materials<br />
# are made available under the terms of the Eclipse Public License 2.0<br />
# which accompanies this distribution, and is available at<br />
# https://www.eclipse.org/legal/epl-2.0/<br />
#<br />
# SPDX-License-Identifier: EPL-2.0<br />
#<br />
# Contributors:<br />
#<br />
###############################################################################<br />
<br />
* '''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.<br />
* '''Strings''': Verify the Non-NLS markers.<br />
* '''Tags''': (@since plugin-number, ...)<br />
/**<br />
* Constructs an Editor for multiple Integer values.<br />
* The widget is a List, with controls to move values up/down, add values and remove values.<br />
*<br />
* @param parent<br />
* The Composite in which this editor is created<br />
* @param directCreation<br />
* Indicates if the creation and modification are directed.<br />
* @param directCreationWithTreeViewer<br />
* Indicates if the creation and modification are directed on the TreeViewer.<br />
* @param style<br />
* The List's style<br />
*<br />
* @since 3.1<br />
*/<br />
public MultipleIntegerEditor(Composite parent, ...){}<br />
<br />
* '''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.<br />
* '''Reexports''': A contributed code should never introduce any 'hidden' dependencies such as reexporting plugins dependencies.<br />
* '''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).<br />
* '''Attributes''': All attributes, field must be at beginning of the class<br />
* '''Returns and conditions''': You can have as many 'return' statement you need in a method.<br />
<br />
* '''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.<br />
<feature <br />
id="org.eclipse.papyrus.XXXXXXX.feature" <br />
version="2.0.0.qualifier"<br />
label="%featureName" <br />
provider-name="%providerName" <br />
license-feature="org.eclipse.license"<br />
license-feature-version="2.0.0"><br />
<br />
<description><br />
%description<br />
</description><br />
<br />
<copyright><br />
%copyright<br />
</copyright><br />
<br />
<license url="%licenseURL"><br />
%license<br />
</license><br />
<br />
<br />
==== String Externalization/Internalization ====<br />
*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,<br />
<br />
Follow this [[Papyrus_Developer_Guide/Externalize_Strings_In_Java | link]] for a guide on externalization in Eclipse.<br />
<br />
=== Write Documentation for Papyrus ===<br />
Each new contribution must contribute to the documentation (behavior changes or new feature). <br />
The documentation must be splitted in two parts: <br />
*user documentation<br />
*developer documentation<br />
<br />
How to - Related to documentation [[Papyrus Developer Guide/Writing Documentation]]<br />
<br />
=== Plugin Versioning - Deprecated code ===<br />
Using the @Deprecated tag, you must do these things in the same time:<br />
*increase the minor version of the plugin (of course, only if it has not yet be done since the last release)<br />
**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.<br />
* indicate in the comment the plugin version when the class/method became deprecated<br />
* open a bug to remove the deprecated class/method in the next major release<br />
* reference this bug in the comment of the deprecated class/method<br />
* (optional) indicate in the comment in which major release the class/method will be remove<br />
<br />
Add the end, you must have something like that: <br />
<br />
<nowiki><br />
/**<br />
*<br />
* @deprecated since 3.1<br />
* use {@link org.eclipse.papyrus.infra.gmfdiag.common.structure.DiagramStructure} API instead<br />
*<br />
* This class will be removed in Papyrus 5.0, see Bug 541027<br />
*<br />
*<br />
*/<br />
@Deprecated<br />
public abstract class DiagramStructure {<br />
...<br />
}<br />
</nowiki><br />
<br />
=== API ===<br />
* Code of plugins shall be inside internal package<br />
* API shall be public and each classe presence shall be justified by implementation of usecase<br />
* The usecase are store inside the plugin the name of the file '''XXX.usecases.md'''<br />
* The grammar is:<br />
### requirement text <br />
* qualified name of the class<br />
<br />
* See the folowing example<br />
<br />
### The profile validation must be done with a button 'Validate Profile plug-in' on plug-in, in the papyrus developer menu<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.handlers.ValidateProfilePluginHandler<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.testers.ValidateProfilePluginTester<br />
* plugin.xml<br />
### During the validation, a progress monitor must be opened with correct explanations<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.handlers.ValidateProfilePluginHandler<br />
### A checker for the extensions must be implemented<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.internal.checkers.ProfileExtensionsChecker<br />
### A checker for the definition profile must be implemented<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.internal.checkers.ProfileDefinitionChecker<br />
<br />
== Contribute ==<br />
<br />
=== CQs ===<br />
* Remember to check on the current CQs to see if they are still current and that we will not miss any currently required dependencies (e.g. glazed lists in the new orbit or the new apache.common.io dependency) as well as the IPlogs. A quick tutorial on CQs can be found [https://wiki.eclipse.org/Papyrus_Developer_Guide/Contribution_Questionaire here].<br />
<br />
=== Gerrit ===<br />
<br />
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]]<br />
<br />
(For further information, see http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf) <br />
<br />
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;: <br />
<br />
*(1) I, Forename Name, wrote 100% of the code I've provided. <br />
*(2) This code contains no cryptography <br />
*(3) I have the right to contribute the code to Eclipse. <br />
*(4) I contribute the content under the EPL.<br />
<br />
+ Set the field Review to '?'.<br />
<br />
=== Commit message ===<br />
*During the commit&nbsp;: <br />
**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.<br />
<br />
<br />
== Code Reviews ==<br />
The reviewer shall verify that the contribution respects all [https://wiki.eclipse.org/Papyrus/Papyrus_Developer_Guide/How_To-_Code_Contributing#Code_Rules aforementioned rules].<br />
<br />
== Merge ==<br />
Eclipse release calendar is detailled [[Simultaneous_Release|here]]. Each date of releases (M1, M2, M3, RC1, RC2 and GA) for the new Eclipse version is defined in a associated wiki page of the Eclipse version). <br />
<br />
Contributions should be merged before:<br />
*M2+<br />
It is forbidden to modify the GUI. Only important bug fixes should be merged. <br />
Creation of a branch (tag) for the release<br />
*M3+<br />
It is forbidden to modify the features and general architecture.<br />
*RC1+<br />
Its forbidden to merge contribution. Only by the project Chief for critical bugs.</div>Patrick.Tessier.cea.frhttps://wiki.eclipse.org/index.php?title=Papyrus/Papyrus_Developer_Guide/How_To-_Code_Contributing&diff=440634Papyrus/Papyrus Developer Guide/How To- Code Contributing2020-09-10T15:02:27Z<p>Patrick.Tessier.cea.fr: /* Code Reviews */</p>
<hr />
<div>__TOC__<br />
<br />
<br />
All papyrus contributors shall follow these rules:<br />
<br />
== Write a Bugzilla task ==<br />
When adding a task to the buzilla, the following grammar should be used: <br />
<br />
*'[' ''Category'' ']' ''NameOfTheTask''<br><br />
<br />
The category helps to filter the bugs for developers. There are already some existing categories: General, XXX Diagram, Common, Property View, etc.<br />
<br />
As a reminder, the lifecycle of bugs is located here: [[Development Resources/HOWTO/Bugzilla Use|Bugzilla Use]]<br />
<br />
*Your contribution shall be associated to a bug refenced in the bugzilla.<br />
*When a bug is opened/resolved/closed the Target Milestone must be filled. For example the bug has been fixed for the service release 3 of oxygen, the target milestone is 3.3.<br />
<br />
<br />
== Write the code ==<br />
<br />
=== Papyrus Plugin Structure ===<br />
<br />
*Papyrus plugin naming scheme and folder structure used to locate and name plugins is described here: [[Papyrus/Papyrus_Developer_Guide/Papyrus_Plugin_Naming_Scheme]]<br />
<br />
*All plug-ins must compile and run against JavaSE-1.8. Papyrus 5.0 must compile against openjdk-11.<br />
*Plug-in provider&nbsp;: ''Eclipse Modeling Project'' <br />
*Version&nbsp;: <br />
***Papyrus adheres to the [[Version Numbering|Eclipse Versioning Guidelines]] for API evolution and other kinds of changes''<br />
*Plug-in name&nbsp;: must end with (Incubation) if version is less than 1.0.0 . If the version is at least 1.0.0, the (Incubation) suffix must be removed.<br />
*Plug-in ID&nbsp;: must start with org.eclipse.papyrus.<br />
*Plug-in dependencies must not be re-exported.<br />
*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"'')<br />
**The Papyrus Developer Tools has 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<br />
*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: <br />
**META-INF/ <br />
**about.html <br />
**icons/, images/, resources/, models/, etc. (All folders containing runtime resources) <br />
**plugin.properties <br />
**plugin.xml <br />
**schema/ <br />
*Do '''not''' include the following files: <br />
**.classpath <br />
**.project <br />
**bin/, src/, src-gen/, custom-src/ <br />
**build.properties <br />
*The ''Source build'' (field src.includes in build.properties) category '''must''' contain the '''about.html''' file: <br />
*It '''must not''' contain the following: <br />
**src/, src-gen/, custom-src/ <br />
**All files and directories are already contained in the "Binary build" category (Except the about.html which must be contained in both Binary and Source builds)<br />
<br />
plugin.xml:<br><br />
[[Image:Papyrus.codestandards.plugin.xml.png]]<br />
<br />
<br />
=== Code Formatting ===<br />
Before writing any code you should check that you have the papyrus templates set as your format in your IDE.<br />
These can be [https://wiki.eclipse.org/Papyrus/Papyrus_Developer_Guide#Apply_Papyrus_Configuration_Files retrieved following these steps].<br />
<br />
These could also be retreived and applied from the .settings folder of each plugins. (An example can be found [https://git.eclipse.org/c/papyrus/org.eclipse.papyrus.git/tree/plugins/infra/core/org.eclipse.papyrus.infra.core.log/.settings here])<br />
<br />
=== Code Rules ===<br />
Before committing, you should verify these items&nbsp;: <br />
*'''default''' keyword in Interfaces: should be avoided and only used if unavoidable and justified (to prevent unnecessary API break for example)<br />
*'''var''' keyword is forbidden<br />
*'''lambda expressions''' are allowed, but must be commented to ease the understanding<br />
*each file has an header with the EPL licence and your name <br />
*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.<br />
*the version numbers are correct. see [https://wiki.eclipse.org/Version_Numbering this guide] for more information.<br />
<br />
==== String Externalization/Internalization ====<br />
*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,<br />
<br />
Follow this [[Papyrus_Developer_Guide/Externalize_Strings_In_Java | link]] for a guide on externalization in Eclipse.<br />
<br />
=== Write Documentation for Papyrus ===<br />
Each new contribution must contribute to the documentation (behavior changes or new feature). <br />
The documentation must be splitted in two parts: <br />
*user documentation<br />
*developer documentation<br />
<br />
How to - Related to documentation [[Papyrus Developer Guide/Writing Documentation]]<br />
<br />
=== Plugin Versioning - Deprecated code ===<br />
Using the @Deprecated tag, you must do these things in the same time:<br />
*increase the minor version of the plugin (of course, only if it has not yet be done since the last release)<br />
**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.<br />
* indicate in the comment the plugin version when the class/method became deprecated<br />
* open a bug to remove the deprecated class/method in the next major release<br />
* reference this bug in the comment of the deprecated class/method<br />
* (optional) indicate in the comment in which major release the class/method will be remove<br />
<br />
Add the end, you must have something like that: <br />
<br />
<nowiki><br />
/**<br />
*<br />
* @deprecated since 3.1<br />
* use {@link org.eclipse.papyrus.infra.gmfdiag.common.structure.DiagramStructure} API instead<br />
*<br />
* This class will be removed in Papyrus 5.0, see Bug 541027<br />
*<br />
*<br />
*/<br />
@Deprecated<br />
public abstract class DiagramStructure {<br />
...<br />
}<br />
</nowiki><br />
<br />
=== API ===<br />
* Code of plugins shall be inside internal package<br />
* API shall be public and each classe presence shall be justified by implementation of usecase<br />
* The usecase are store inside the plugin the name of the file '''XXX.usecases.md'''<br />
* The grammar is:<br />
### requirement text <br />
* qualified name of the class<br />
<br />
* See the folowing example<br />
<br />
### The profile validation must be done with a button 'Validate Profile plug-in' on plug-in, in the papyrus developer menu<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.handlers.ValidateProfilePluginHandler<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.testers.ValidateProfilePluginTester<br />
* plugin.xml<br />
### During the validation, a progress monitor must be opened with correct explanations<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.handlers.ValidateProfilePluginHandler<br />
### A checker for the extensions must be implemented<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.internal.checkers.ProfileExtensionsChecker<br />
### A checker for the definition profile must be implemented<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.internal.checkers.ProfileDefinitionChecker<br />
<br />
== Contribute ==<br />
<br />
=== CQs ===<br />
* Remember to check on the current CQs to see if they are still current and that we will not miss any currently required dependencies (e.g. glazed lists in the new orbit or the new apache.common.io dependency) as well as the IPlogs. A quick tutorial on CQs can be found [https://wiki.eclipse.org/Papyrus_Developer_Guide/Contribution_Questionaire here].<br />
<br />
=== Gerrit ===<br />
<br />
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]]<br />
<br />
(For further information, see http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf) <br />
<br />
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;: <br />
<br />
*(1) I, Forename Name, wrote 100% of the code I've provided. <br />
*(2) This code contains no cryptography <br />
*(3) I have the right to contribute the code to Eclipse. <br />
*(4) I contribute the content under the EPL.<br />
<br />
+ Set the field Review to '?'.<br />
<br />
=== Commit message ===<br />
*During the commit&nbsp;: <br />
**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.<br />
<br />
<br />
== Code Reviews ==<br />
The reviewer shall verify that the contribution respects all [https://wiki.eclipse.org/Papyrus/Papyrus_Developer_Guide/How_To-_Code_Contributing#Code_Rules aforementioned rules].<br />
<br />
== Merge ==<br />
Eclipse release calendar is detailled [[Simultaneous_Release|here]]. Each date of releases (M1, M2, M3, RC1, RC2 and GA) for the new Eclipse version is defined in a associated wiki page of the Eclipse version). <br />
<br />
Contributions should be merged before:<br />
*M2+<br />
It is forbidden to modify the GUI. Only important bug fixes should be merged. <br />
Creation of a branch (tag) for the release<br />
*M3+<br />
It is forbidden to modify the features and general architecture.<br />
*RC1+<br />
Its forbidden to merge contribution. Only by the project Chief for critical bugs.</div>Patrick.Tessier.cea.frhttps://wiki.eclipse.org/index.php?title=Papyrus/Papyrus_Developer_Guide/How_To-_Code_Contributing&diff=440633Papyrus/Papyrus Developer Guide/How To- Code Contributing2020-09-10T15:00:12Z<p>Patrick.Tessier.cea.fr: /* What to check before committing a patch */</p>
<hr />
<div>__TOC__<br />
<br />
<br />
All papyrus contributors shall follow these rules:<br />
<br />
== Write a Bugzilla task ==<br />
When adding a task to the buzilla, the following grammar should be used: <br />
<br />
*'[' ''Category'' ']' ''NameOfTheTask''<br><br />
<br />
The category helps to filter the bugs for developers. There are already some existing categories: General, XXX Diagram, Common, Property View, etc.<br />
<br />
As a reminder, the lifecycle of bugs is located here: [[Development Resources/HOWTO/Bugzilla Use|Bugzilla Use]]<br />
<br />
*Your contribution shall be associated to a bug refenced in the bugzilla.<br />
*When a bug is opened/resolved/closed the Target Milestone must be filled. For example the bug has been fixed for the service release 3 of oxygen, the target milestone is 3.3.<br />
<br />
<br />
== Write the code ==<br />
<br />
=== Papyrus Plugin Structure ===<br />
<br />
*Papyrus plugin naming scheme and folder structure used to locate and name plugins is described here: [[Papyrus/Papyrus_Developer_Guide/Papyrus_Plugin_Naming_Scheme]]<br />
<br />
*All plug-ins must compile and run against JavaSE-1.8. Papyrus 5.0 must compile against openjdk-11.<br />
*Plug-in provider&nbsp;: ''Eclipse Modeling Project'' <br />
*Version&nbsp;: <br />
***Papyrus adheres to the [[Version Numbering|Eclipse Versioning Guidelines]] for API evolution and other kinds of changes''<br />
*Plug-in name&nbsp;: must end with (Incubation) if version is less than 1.0.0 . If the version is at least 1.0.0, the (Incubation) suffix must be removed.<br />
*Plug-in ID&nbsp;: must start with org.eclipse.papyrus.<br />
*Plug-in dependencies must not be re-exported.<br />
*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"'')<br />
**The Papyrus Developer Tools has 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<br />
*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: <br />
**META-INF/ <br />
**about.html <br />
**icons/, images/, resources/, models/, etc. (All folders containing runtime resources) <br />
**plugin.properties <br />
**plugin.xml <br />
**schema/ <br />
*Do '''not''' include the following files: <br />
**.classpath <br />
**.project <br />
**bin/, src/, src-gen/, custom-src/ <br />
**build.properties <br />
*The ''Source build'' (field src.includes in build.properties) category '''must''' contain the '''about.html''' file: <br />
*It '''must not''' contain the following: <br />
**src/, src-gen/, custom-src/ <br />
**All files and directories are already contained in the "Binary build" category (Except the about.html which must be contained in both Binary and Source builds)<br />
<br />
plugin.xml:<br><br />
[[Image:Papyrus.codestandards.plugin.xml.png]]<br />
<br />
<br />
=== Code Formatting ===<br />
Before writing any code you should check that you have the papyrus templates set as your format in your IDE.<br />
These can be [https://wiki.eclipse.org/Papyrus/Papyrus_Developer_Guide#Apply_Papyrus_Configuration_Files retrieved following these steps].<br />
<br />
These could also be retreived and applied from the .settings folder of each plugins. (An example can be found [https://git.eclipse.org/c/papyrus/org.eclipse.papyrus.git/tree/plugins/infra/core/org.eclipse.papyrus.infra.core.log/.settings here])<br />
<br />
=== Code Rules ===<br />
Before committing, you should verify these items&nbsp;: <br />
*'''default''' keyword in Interfaces: should be avoided and only used if unavoidable and justified (to prevent unnecessary API break for example)<br />
*'''var''' keyword is forbidden<br />
*'''lambda expressions''' are allowed, but must be commented to ease the understanding<br />
*each file has an header with the EPL licence and your name <br />
*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.<br />
*the version numbers are correct. see [https://wiki.eclipse.org/Version_Numbering this guide] for more information.<br />
<br />
==== String Externalization/Internalization ====<br />
*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,<br />
<br />
Follow this [[Papyrus_Developer_Guide/Externalize_Strings_In_Java | link]] for a guide on externalization in Eclipse.<br />
<br />
=== Write Documentation for Papyrus ===<br />
Each new contribution must contribute to the documentation (behavior changes or new feature). <br />
The documentation must be splitted in two parts: <br />
*user documentation<br />
*developer documentation<br />
<br />
How to - Related to documentation [[Papyrus Developer Guide/Writing Documentation]]<br />
<br />
=== Plugin Versioning - Deprecated code ===<br />
Using the @Deprecated tag, you must do these things in the same time:<br />
*increase the minor version of the plugin (of course, only if it has not yet be done since the last release)<br />
**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.<br />
* indicate in the comment the plugin version when the class/method became deprecated<br />
* open a bug to remove the deprecated class/method in the next major release<br />
* reference this bug in the comment of the deprecated class/method<br />
* (optional) indicate in the comment in which major release the class/method will be remove<br />
<br />
Add the end, you must have something like that: <br />
<br />
<nowiki><br />
/**<br />
*<br />
* @deprecated since 3.1<br />
* use {@link org.eclipse.papyrus.infra.gmfdiag.common.structure.DiagramStructure} API instead<br />
*<br />
* This class will be removed in Papyrus 5.0, see Bug 541027<br />
*<br />
*<br />
*/<br />
@Deprecated<br />
public abstract class DiagramStructure {<br />
...<br />
}<br />
</nowiki><br />
<br />
=== API ===<br />
* Code of plugins shall be inside internal package<br />
* API shall be public and each classe presence shall be justified by implementation of usecase<br />
* The usecase are store inside the plugin the name of the file '''XXX.usecases.md'''<br />
* The grammar is:<br />
### requirement text <br />
* qualified name of the class<br />
<br />
* See the folowing example<br />
<br />
### The profile validation must be done with a button 'Validate Profile plug-in' on plug-in, in the papyrus developer menu<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.handlers.ValidateProfilePluginHandler<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.testers.ValidateProfilePluginTester<br />
* plugin.xml<br />
### During the validation, a progress monitor must be opened with correct explanations<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.handlers.ValidateProfilePluginHandler<br />
### A checker for the extensions must be implemented<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.internal.checkers.ProfileExtensionsChecker<br />
### A checker for the definition profile must be implemented<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.internal.checkers.ProfileDefinitionChecker<br />
<br />
== Contribute ==<br />
<br />
=== CQs ===<br />
* Remember to check on the current CQs to see if they are still current and that we will not miss any currently required dependencies (e.g. glazed lists in the new orbit or the new apache.common.io dependency) as well as the IPlogs. A quick tutorial on CQs can be found [https://wiki.eclipse.org/Papyrus_Developer_Guide/Contribution_Questionaire here].<br />
<br />
=== Gerrit ===<br />
<br />
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]]<br />
<br />
(For further information, see http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf) <br />
<br />
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;: <br />
<br />
*(1) I, Forename Name, wrote 100% of the code I've provided. <br />
*(2) This code contains no cryptography <br />
*(3) I have the right to contribute the code to Eclipse. <br />
*(4) I contribute the content under the EPL.<br />
<br />
+ Set the field Review to '?'.<br />
<br />
=== Commit message ===<br />
*During the commit&nbsp;: <br />
**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.<br />
<br />
<br />
== Code Reviews ==<br />
<br />
== Merge ==<br />
Eclipse release calendar is detailled [[Simultaneous_Release|here]]. Each date of releases (M1, M2, M3, RC1, RC2 and GA) for the new Eclipse version is defined in a associated wiki page of the Eclipse version). <br />
<br />
Contributions should be merged before:<br />
*M2+<br />
It is forbidden to modify the GUI. Only important bug fixes should be merged. <br />
Creation of a branch (tag) for the release<br />
*M3+<br />
It is forbidden to modify the features and general architecture.<br />
*RC1+<br />
Its forbidden to merge contribution. Only by the project Chief for critical bugs.</div>Patrick.Tessier.cea.frhttps://wiki.eclipse.org/index.php?title=Papyrus/Papyrus_Developer_Guide/How_To-_Code_Contributing&diff=440631Papyrus/Papyrus Developer Guide/How To- Code Contributing2020-09-10T14:59:14Z<p>Patrick.Tessier.cea.fr: /* String Externalization/Internalization */</p>
<hr />
<div>__TOC__<br />
<br />
<br />
All papyrus contributors shall follow these rules:<br />
<br />
== Write a Bugzilla task ==<br />
When adding a task to the buzilla, the following grammar should be used: <br />
<br />
*'[' ''Category'' ']' ''NameOfTheTask''<br><br />
<br />
The category helps to filter the bugs for developers. There are already some existing categories: General, XXX Diagram, Common, Property View, etc.<br />
<br />
As a reminder, the lifecycle of bugs is located here: [[Development Resources/HOWTO/Bugzilla Use|Bugzilla Use]]<br />
<br />
*Your contribution shall be associated to a bug refenced in the bugzilla.<br />
*When a bug is opened/resolved/closed the Target Milestone must be filled. For example the bug has been fixed for the service release 3 of oxygen, the target milestone is 3.3.<br />
<br />
<br />
== Write the code ==<br />
<br />
=== Papyrus Plugin Structure ===<br />
<br />
*Papyrus plugin naming scheme and folder structure used to locate and name plugins is described here: [[Papyrus/Papyrus_Developer_Guide/Papyrus_Plugin_Naming_Scheme]]<br />
<br />
*All plug-ins must compile and run against JavaSE-1.8. Papyrus 5.0 must compile against openjdk-11.<br />
*Plug-in provider&nbsp;: ''Eclipse Modeling Project'' <br />
*Version&nbsp;: <br />
***Papyrus adheres to the [[Version Numbering|Eclipse Versioning Guidelines]] for API evolution and other kinds of changes''<br />
*Plug-in name&nbsp;: must end with (Incubation) if version is less than 1.0.0 . If the version is at least 1.0.0, the (Incubation) suffix must be removed.<br />
*Plug-in ID&nbsp;: must start with org.eclipse.papyrus.<br />
*Plug-in dependencies must not be re-exported.<br />
*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"'')<br />
**The Papyrus Developer Tools has 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<br />
*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: <br />
**META-INF/ <br />
**about.html <br />
**icons/, images/, resources/, models/, etc. (All folders containing runtime resources) <br />
**plugin.properties <br />
**plugin.xml <br />
**schema/ <br />
*Do '''not''' include the following files: <br />
**.classpath <br />
**.project <br />
**bin/, src/, src-gen/, custom-src/ <br />
**build.properties <br />
*The ''Source build'' (field src.includes in build.properties) category '''must''' contain the '''about.html''' file: <br />
*It '''must not''' contain the following: <br />
**src/, src-gen/, custom-src/ <br />
**All files and directories are already contained in the "Binary build" category (Except the about.html which must be contained in both Binary and Source builds)<br />
<br />
plugin.xml:<br><br />
[[Image:Papyrus.codestandards.plugin.xml.png]]<br />
<br />
<br />
=== Code Formatting ===<br />
Before writing any code you should check that you have the papyrus templates set as your format in your IDE.<br />
These can be [https://wiki.eclipse.org/Papyrus/Papyrus_Developer_Guide#Apply_Papyrus_Configuration_Files retrieved following these steps].<br />
<br />
These could also be retreived and applied from the .settings folder of each plugins. (An example can be found [https://git.eclipse.org/c/papyrus/org.eclipse.papyrus.git/tree/plugins/infra/core/org.eclipse.papyrus.infra.core.log/.settings here])<br />
<br />
=== Code Rules ===<br />
Before committing, you should verify these items&nbsp;: <br />
*'''default''' keyword in Interfaces: should be avoided and only used if unavoidable and justified (to prevent unnecessary API break for example)<br />
*'''var''' keyword is forbidden<br />
*'''lambda expressions''' are allowed, but must be commented to ease the understanding<br />
*each file has an header with the EPL licence and your name <br />
*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.<br />
*the version numbers are correcct. see [https://wiki.eclipse.org/Version_Numbering this guide] for more information.<br />
<br />
==== String Externalization/Internalization ====<br />
*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,<br />
<br />
Follow this [[Papyrus_Developer_Guide/Externalize_Strings_In_Java | link]] for a guide on externalization in Eclipse.<br />
<br />
=== Write Documentation for Papyrus ===<br />
Each new contribution must contribute to the documentation (behavior changes or new feature). <br />
The documentation must be splitted in two parts: <br />
*user documentation<br />
*developer documentation<br />
<br />
How to - Related to documentation [[Papyrus Developer Guide/Writing Documentation]]<br />
<br />
=== Plugin Versioning - Deprecated code ===<br />
Using the @Deprecated tag, you must do these things in the same time:<br />
*increase the minor version of the plugin (of course, only if it has not yet be done since the last release)<br />
**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.<br />
* indicate in the comment the plugin version when the class/method became deprecated<br />
* open a bug to remove the deprecated class/method in the next major release<br />
* reference this bug in the comment of the deprecated class/method<br />
* (optional) indicate in the comment in which major release the class/method will be remove<br />
<br />
Add the end, you must have something like that: <br />
<br />
<nowiki><br />
/**<br />
*<br />
* @deprecated since 3.1<br />
* use {@link org.eclipse.papyrus.infra.gmfdiag.common.structure.DiagramStructure} API instead<br />
*<br />
* This class will be removed in Papyrus 5.0, see Bug 541027<br />
*<br />
*<br />
*/<br />
@Deprecated<br />
public abstract class DiagramStructure {<br />
...<br />
}<br />
</nowiki><br />
<br />
=== API ===<br />
* Code of plugins shall be inside internal package<br />
* API shall be public and each classe presence shall be justified by implementation of usecase<br />
* The usecase are store inside the plugin the name of the file '''XXX.usecases.md'''<br />
* The grammar is:<br />
### requirement text <br />
* qualified name of the class<br />
<br />
* See the folowing example<br />
<br />
### The profile validation must be done with a button 'Validate Profile plug-in' on plug-in, in the papyrus developer menu<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.handlers.ValidateProfilePluginHandler<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.testers.ValidateProfilePluginTester<br />
* plugin.xml<br />
### During the validation, a progress monitor must be opened with correct explanations<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.handlers.ValidateProfilePluginHandler<br />
### A checker for the extensions must be implemented<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.internal.checkers.ProfileExtensionsChecker<br />
### A checker for the definition profile must be implemented<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.internal.checkers.ProfileDefinitionChecker<br />
<br />
== Contribute ==<br />
<br />
=== CQs ===<br />
* Remember to check on the current CQs to see if they are still current and that we will not miss any currently required dependencies (e.g. glazed lists in the new orbit or the new apache.common.io dependency) as well as the IPlogs. A quick tutorial on CQs can be found [https://wiki.eclipse.org/Papyrus_Developer_Guide/Contribution_Questionaire here].<br />
<br />
=== Gerrit ===<br />
<br />
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]]<br />
<br />
(For further information, see http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf) <br />
<br />
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;: <br />
<br />
*(1) I, Forename Name, wrote 100% of the code I've provided. <br />
*(2) This code contains no cryptography <br />
*(3) I have the right to contribute the code to Eclipse. <br />
*(4) I contribute the content under the EPL.<br />
<br />
+ Set the field Review to '?'.<br />
<br />
=== Commit message ===<br />
*During the commit&nbsp;: <br />
**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.<br />
<br />
<br />
== Code Reviews ==<br />
<br />
=== What to check before committing a patch ===<br />
<br />
Before commiting a patch, you should verify that the contributor has written the following lines in the comment&nbsp;: <br />
<br />
*(1) I, Forename Name, wrote 100% of the code I've provided. <br />
*(2) This code contains no cryptography <br />
*(3) I have the right to contribute the code to Eclipse. <br />
*(4) I contribute the content under the EPL.<br />
<br />
If not, he must do that before you commit its patch! <br />
<br />
*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;: <br />
**Here is a contribution from one employee of "the name of the company" <br />
**The company has signed a Member Commiter Agreement. <br />
**The contribution does not need a CQ. <br />
**I've committed this contribution. <br />
**Committed revision xxx. <br />
**Set the field iplog to +<br />
<br />
Note&nbsp;: In reality, you should have the autorization of the PMC before doing this commit. <br />
<br />
*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.<br />
<br />
*In all other cases, see http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf<br />
<br />
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/><br />
Here are some guidelines (which may be altered and/or improved) that every reviewer and committer should follow:<br />
* '''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.<br />
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.<br />
/*****************************************************************************<br />
* Copyright (c) 2015, 2018 CEA LIST, Committer Name, and others.<br />
*<br />
* All rights reserved. This program and the accompanying materials<br />
* are made available under the terms of the Eclipse Public License 2.0<br />
* which accompanies this distribution, and is available at<br />
* https://www.eclipse.org/legal/epl-2.0/<br />
*<br />
* SPDX-License-Identifier: EPL-2.0<br />
*<br />
* Contributors:<br />
* CEA LIST - Initial API and implementation<br />
* Committer Name (CEA LIST) committer.name@cea.fr - Bug 492522, Bug XXXXXX<br />
*****************************************************************************/<br />
<br />
###############################################################################<br />
# Copyright (c) 2013, 2018 CEA LIST, Committer Name, and others.<br />
#<br />
# All rights reserved. This program and the accompanying materials<br />
# are made available under the terms of the Eclipse Public License 2.0<br />
# which accompanies this distribution, and is available at<br />
# https://www.eclipse.org/legal/epl-2.0/<br />
#<br />
# SPDX-License-Identifier: EPL-2.0<br />
#<br />
# Contributors:<br />
#<br />
###############################################################################<br />
<br />
* '''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.<br />
* '''Strings''': Verify the Non-NLS markers.<br />
* '''Tags''': (@since plugin-number, ...)<br />
/**<br />
* Constructs an Editor for multiple Integer values.<br />
* The widget is a List, with controls to move values up/down, add values and remove values.<br />
*<br />
* @param parent<br />
* The Composite in which this editor is created<br />
* @param directCreation<br />
* Indicates if the creation and modification are directed.<br />
* @param directCreationWithTreeViewer<br />
* Indicates if the creation and modification are directed on the TreeViewer.<br />
* @param style<br />
* The List's style<br />
*<br />
* @since 3.1<br />
*/<br />
public MultipleIntegerEditor(Composite parent, ...){}<br />
<br />
* '''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.<br />
* '''Reexports''': A contributed code should never introduce any 'hidden' dependencies such as reexporting plugins dependencies.<br />
* '''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).<br />
* '''Attributes''': All attributes, field must be at beginning of the class<br />
* '''Returns and conditions''': You can have as many 'return' statement you need in a method.<br />
<br />
* '''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.<br />
<feature <br />
id="org.eclipse.papyrus.XXXXXXX.feature" <br />
version="2.0.0.qualifier"<br />
label="%featureName" <br />
provider-name="%providerName" <br />
license-feature="org.eclipse.license"<br />
license-feature-version="2.0.0"><br />
<br />
<description><br />
%description<br />
</description><br />
<br />
<copyright><br />
%copyright<br />
</copyright><br />
<br />
<license url="%licenseURL"><br />
%license<br />
</license><br />
<br />
<br />
== Merge ==<br />
Eclipse release calendar is detailled [[Simultaneous_Release|here]]. Each date of releases (M1, M2, M3, RC1, RC2 and GA) for the new Eclipse version is defined in a associated wiki page of the Eclipse version). <br />
<br />
Contributions should be merged before:<br />
*M2+<br />
It is forbidden to modify the GUI. Only important bug fixes should be merged. <br />
Creation of a branch (tag) for the release<br />
*M3+<br />
It is forbidden to modify the features and general architecture.<br />
*RC1+<br />
Its forbidden to merge contribution. Only by the project Chief for critical bugs.</div>Patrick.Tessier.cea.frhttps://wiki.eclipse.org/index.php?title=Papyrus/Papyrus_Developer_Guide/How_To-_Code_Contributing&diff=440632Papyrus/Papyrus Developer Guide/How To- Code Contributing2020-09-10T14:58:02Z<p>Patrick.Tessier.cea.fr: /* Code Rules */</p>
<hr />
<div>__TOC__<br />
<br />
<br />
All papyrus contributors shall follow these rules:<br />
<br />
== Write a Bugzilla task ==<br />
When adding a task to the buzilla, the following grammar should be used: <br />
<br />
*'[' ''Category'' ']' ''NameOfTheTask''<br><br />
<br />
The category helps to filter the bugs for developers. There are already some existing categories: General, XXX Diagram, Common, Property View, etc.<br />
<br />
As a reminder, the lifecycle of bugs is located here: [[Development Resources/HOWTO/Bugzilla Use|Bugzilla Use]]<br />
<br />
*Your contribution shall be associated to a bug refenced in the bugzilla.<br />
*When a bug is opened/resolved/closed the Target Milestone must be filled. For example the bug has been fixed for the service release 3 of oxygen, the target milestone is 3.3.<br />
<br />
<br />
== Write the code ==<br />
<br />
=== Papyrus Plugin Structure ===<br />
<br />
*Papyrus plugin naming scheme and folder structure used to locate and name plugins is described here: [[Papyrus/Papyrus_Developer_Guide/Papyrus_Plugin_Naming_Scheme]]<br />
<br />
*All plug-ins must compile and run against JavaSE-1.8. Papyrus 5.0 must compile against openjdk-11.<br />
*Plug-in provider&nbsp;: ''Eclipse Modeling Project'' <br />
*Version&nbsp;: <br />
***Papyrus adheres to the [[Version Numbering|Eclipse Versioning Guidelines]] for API evolution and other kinds of changes''<br />
*Plug-in name&nbsp;: must end with (Incubation) if version is less than 1.0.0 . If the version is at least 1.0.0, the (Incubation) suffix must be removed.<br />
*Plug-in ID&nbsp;: must start with org.eclipse.papyrus.<br />
*Plug-in dependencies must not be re-exported.<br />
*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"'')<br />
**The Papyrus Developer Tools has 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<br />
*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: <br />
**META-INF/ <br />
**about.html <br />
**icons/, images/, resources/, models/, etc. (All folders containing runtime resources) <br />
**plugin.properties <br />
**plugin.xml <br />
**schema/ <br />
*Do '''not''' include the following files: <br />
**.classpath <br />
**.project <br />
**bin/, src/, src-gen/, custom-src/ <br />
**build.properties <br />
*The ''Source build'' (field src.includes in build.properties) category '''must''' contain the '''about.html''' file: <br />
*It '''must not''' contain the following: <br />
**src/, src-gen/, custom-src/ <br />
**All files and directories are already contained in the "Binary build" category (Except the about.html which must be contained in both Binary and Source builds)<br />
<br />
plugin.xml:<br><br />
[[Image:Papyrus.codestandards.plugin.xml.png]]<br />
<br />
<br />
=== Code Formatting ===<br />
Before writing any code you should check that you have the papyrus templates set as your format in your IDE.<br />
These can be [https://wiki.eclipse.org/Papyrus/Papyrus_Developer_Guide#Apply_Papyrus_Configuration_Files retrieved following these steps].<br />
<br />
These could also be retreived and applied from the .settings folder of each plugins. (An example can be found [https://git.eclipse.org/c/papyrus/org.eclipse.papyrus.git/tree/plugins/infra/core/org.eclipse.papyrus.infra.core.log/.settings here])<br />
<br />
=== Code Rules ===<br />
Before committing, you should verify these items&nbsp;: <br />
*'''default''' keyword in Interfaces: should be avoided and only used if unavoidable and justified (to prevent unnecessary API break for example)<br />
*'''var''' keyword is forbidden<br />
*'''lambda expressions''' are allowed, but must be commented to ease the understanding<br />
*each file has an header with the EPL licence and your name <br />
*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.<br />
*the version numbers are correct. see [https://wiki.eclipse.org/Version_Numbering this guide] for more information.<br />
<br />
==== String Externalization/Internalization ====<br />
*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,<br />
<br />
Follow this [[Papyrus_Developer_Guide/Externalize_Strings_In_Java | link]] for a guide on externalization in Eclipse.<br />
<br />
=== Write Documentation for Papyrus ===<br />
Each new contribution must contribute to the documentation (behavior changes or new feature). <br />
The documentation must be splitted in two parts: <br />
*user documentation<br />
*developer documentation<br />
<br />
How to - Related to documentation [[Papyrus Developer Guide/Writing Documentation]]<br />
<br />
=== Plugin Versioning - Deprecated code ===<br />
Using the @Deprecated tag, you must do these things in the same time:<br />
*increase the minor version of the plugin (of course, only if it has not yet be done since the last release)<br />
**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.<br />
* indicate in the comment the plugin version when the class/method became deprecated<br />
* open a bug to remove the deprecated class/method in the next major release<br />
* reference this bug in the comment of the deprecated class/method<br />
* (optional) indicate in the comment in which major release the class/method will be remove<br />
<br />
Add the end, you must have something like that: <br />
<br />
<nowiki><br />
/**<br />
*<br />
* @deprecated since 3.1<br />
* use {@link org.eclipse.papyrus.infra.gmfdiag.common.structure.DiagramStructure} API instead<br />
*<br />
* This class will be removed in Papyrus 5.0, see Bug 541027<br />
*<br />
*<br />
*/<br />
@Deprecated<br />
public abstract class DiagramStructure {<br />
...<br />
}<br />
</nowiki><br />
<br />
=== API ===<br />
* Code of plugins shall be inside internal package<br />
* API shall be public and each classe presence shall be justified by implementation of usecase<br />
* The usecase are store inside the plugin the name of the file '''XXX.usecases.md'''<br />
* The grammar is:<br />
### requirement text <br />
* qualified name of the class<br />
<br />
* See the folowing example<br />
<br />
### The profile validation must be done with a button 'Validate Profile plug-in' on plug-in, in the papyrus developer menu<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.handlers.ValidateProfilePluginHandler<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.testers.ValidateProfilePluginTester<br />
* plugin.xml<br />
### During the validation, a progress monitor must be opened with correct explanations<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.handlers.ValidateProfilePluginHandler<br />
### A checker for the extensions must be implemented<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.internal.checkers.ProfileExtensionsChecker<br />
### A checker for the definition profile must be implemented<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.internal.checkers.ProfileDefinitionChecker<br />
<br />
== Contribute ==<br />
<br />
=== CQs ===<br />
* Remember to check on the current CQs to see if they are still current and that we will not miss any currently required dependencies (e.g. glazed lists in the new orbit or the new apache.common.io dependency) as well as the IPlogs. A quick tutorial on CQs can be found [https://wiki.eclipse.org/Papyrus_Developer_Guide/Contribution_Questionaire here].<br />
<br />
=== Gerrit ===<br />
<br />
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]]<br />
<br />
(For further information, see http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf) <br />
<br />
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;: <br />
<br />
*(1) I, Forename Name, wrote 100% of the code I've provided. <br />
*(2) This code contains no cryptography <br />
*(3) I have the right to contribute the code to Eclipse. <br />
*(4) I contribute the content under the EPL.<br />
<br />
+ Set the field Review to '?'.<br />
<br />
=== Commit message ===<br />
*During the commit&nbsp;: <br />
**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.<br />
<br />
<br />
== Code Reviews ==<br />
<br />
=== What to check before committing a patch ===<br />
<br />
Before commiting a patch, you should verify that the contributor has written the following lines in the comment&nbsp;: <br />
<br />
*(1) I, Forename Name, wrote 100% of the code I've provided. <br />
*(2) This code contains no cryptography <br />
*(3) I have the right to contribute the code to Eclipse. <br />
*(4) I contribute the content under the EPL.<br />
<br />
If not, he must do that before you commit its patch! <br />
<br />
*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;: <br />
**Here is a contribution from one employee of "the name of the company" <br />
**The company has signed a Member Commiter Agreement. <br />
**The contribution does not need a CQ. <br />
**I've committed this contribution. <br />
**Committed revision xxx. <br />
**Set the field iplog to +<br />
<br />
Note&nbsp;: In reality, you should have the autorization of the PMC before doing this commit. <br />
<br />
*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.<br />
<br />
*In all other cases, see http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf<br />
<br />
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/><br />
Here are some guidelines (which may be altered and/or improved) that every reviewer and committer should follow:<br />
* '''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.<br />
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.<br />
/*****************************************************************************<br />
* Copyright (c) 2015, 2018 CEA LIST, Committer Name, and others.<br />
*<br />
* All rights reserved. This program and the accompanying materials<br />
* are made available under the terms of the Eclipse Public License 2.0<br />
* which accompanies this distribution, and is available at<br />
* https://www.eclipse.org/legal/epl-2.0/<br />
*<br />
* SPDX-License-Identifier: EPL-2.0<br />
*<br />
* Contributors:<br />
* CEA LIST - Initial API and implementation<br />
* Committer Name (CEA LIST) committer.name@cea.fr - Bug 492522, Bug XXXXXX<br />
*****************************************************************************/<br />
<br />
###############################################################################<br />
# Copyright (c) 2013, 2018 CEA LIST, Committer Name, and others.<br />
#<br />
# All rights reserved. This program and the accompanying materials<br />
# are made available under the terms of the Eclipse Public License 2.0<br />
# which accompanies this distribution, and is available at<br />
# https://www.eclipse.org/legal/epl-2.0/<br />
#<br />
# SPDX-License-Identifier: EPL-2.0<br />
#<br />
# Contributors:<br />
#<br />
###############################################################################<br />
<br />
* '''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.<br />
* '''Strings''': Verify the Non-NLS markers.<br />
* '''Tags''': (@since plugin-number, ...)<br />
/**<br />
* Constructs an Editor for multiple Integer values.<br />
* The widget is a List, with controls to move values up/down, add values and remove values.<br />
*<br />
* @param parent<br />
* The Composite in which this editor is created<br />
* @param directCreation<br />
* Indicates if the creation and modification are directed.<br />
* @param directCreationWithTreeViewer<br />
* Indicates if the creation and modification are directed on the TreeViewer.<br />
* @param style<br />
* The List's style<br />
*<br />
* @since 3.1<br />
*/<br />
public MultipleIntegerEditor(Composite parent, ...){}<br />
<br />
* '''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.<br />
* '''Reexports''': A contributed code should never introduce any 'hidden' dependencies such as reexporting plugins dependencies.<br />
* '''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).<br />
* '''Attributes''': All attributes, field must be at beginning of the class<br />
* '''Returns and conditions''': You can have as many 'return' statement you need in a method.<br />
<br />
* '''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.<br />
<feature <br />
id="org.eclipse.papyrus.XXXXXXX.feature" <br />
version="2.0.0.qualifier"<br />
label="%featureName" <br />
provider-name="%providerName" <br />
license-feature="org.eclipse.license"<br />
license-feature-version="2.0.0"><br />
<br />
<description><br />
%description<br />
</description><br />
<br />
<copyright><br />
%copyright<br />
</copyright><br />
<br />
<license url="%licenseURL"><br />
%license<br />
</license><br />
<br />
<br />
== Merge ==<br />
Eclipse release calendar is detailled [[Simultaneous_Release|here]]. Each date of releases (M1, M2, M3, RC1, RC2 and GA) for the new Eclipse version is defined in a associated wiki page of the Eclipse version). <br />
<br />
Contributions should be merged before:<br />
*M2+<br />
It is forbidden to modify the GUI. Only important bug fixes should be merged. <br />
Creation of a branch (tag) for the release<br />
*M3+<br />
It is forbidden to modify the features and general architecture.<br />
*RC1+<br />
Its forbidden to merge contribution. Only by the project Chief for critical bugs.</div>Patrick.Tessier.cea.frhttps://wiki.eclipse.org/index.php?title=Papyrus/Papyrus_Developer_Guide/How_To-_Code_Contributing&diff=440630Papyrus/Papyrus Developer Guide/How To- Code Contributing2020-09-10T14:56:57Z<p>Patrick.Tessier.cea.fr: /* Code formatting */</p>
<hr />
<div>__TOC__<br />
<br />
<br />
All papyrus contributors shall follow these rules:<br />
<br />
== Write a Bugzilla task ==<br />
When adding a task to the buzilla, the following grammar should be used: <br />
<br />
*'[' ''Category'' ']' ''NameOfTheTask''<br><br />
<br />
The category helps to filter the bugs for developers. There are already some existing categories: General, XXX Diagram, Common, Property View, etc.<br />
<br />
As a reminder, the lifecycle of bugs is located here: [[Development Resources/HOWTO/Bugzilla Use|Bugzilla Use]]<br />
<br />
*Your contribution shall be associated to a bug refenced in the bugzilla.<br />
*When a bug is opened/resolved/closed the Target Milestone must be filled. For example the bug has been fixed for the service release 3 of oxygen, the target milestone is 3.3.<br />
<br />
<br />
== Write the code ==<br />
<br />
=== Papyrus Plugin Structure ===<br />
<br />
*Papyrus plugin naming scheme and folder structure used to locate and name plugins is described here: [[Papyrus/Papyrus_Developer_Guide/Papyrus_Plugin_Naming_Scheme]]<br />
<br />
*All plug-ins must compile and run against JavaSE-1.8. Papyrus 5.0 must compile against openjdk-11.<br />
*Plug-in provider&nbsp;: ''Eclipse Modeling Project'' <br />
*Version&nbsp;: <br />
***Papyrus adheres to the [[Version Numbering|Eclipse Versioning Guidelines]] for API evolution and other kinds of changes''<br />
*Plug-in name&nbsp;: must end with (Incubation) if version is less than 1.0.0 . If the version is at least 1.0.0, the (Incubation) suffix must be removed.<br />
*Plug-in ID&nbsp;: must start with org.eclipse.papyrus.<br />
*Plug-in dependencies must not be re-exported.<br />
*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"'')<br />
**The Papyrus Developer Tools has 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<br />
*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: <br />
**META-INF/ <br />
**about.html <br />
**icons/, images/, resources/, models/, etc. (All folders containing runtime resources) <br />
**plugin.properties <br />
**plugin.xml <br />
**schema/ <br />
*Do '''not''' include the following files: <br />
**.classpath <br />
**.project <br />
**bin/, src/, src-gen/, custom-src/ <br />
**build.properties <br />
*The ''Source build'' (field src.includes in build.properties) category '''must''' contain the '''about.html''' file: <br />
*It '''must not''' contain the following: <br />
**src/, src-gen/, custom-src/ <br />
**All files and directories are already contained in the "Binary build" category (Except the about.html which must be contained in both Binary and Source builds)<br />
<br />
plugin.xml:<br><br />
[[Image:Papyrus.codestandards.plugin.xml.png]]<br />
<br />
<br />
=== Code Formatting ===<br />
Before writing any code you should check that you have the papyrus templates set as your format in your IDE.<br />
These can be [https://wiki.eclipse.org/Papyrus/Papyrus_Developer_Guide#Apply_Papyrus_Configuration_Files retrieved following these steps].<br />
<br />
These could also be retreived and applied from the .settings folder of each plugins. (An example can be found [https://git.eclipse.org/c/papyrus/org.eclipse.papyrus.git/tree/plugins/infra/core/org.eclipse.papyrus.infra.core.log/.settings here])<br />
<br />
=== Code Rules ===<br />
Before committing, you should verify these items&nbsp;: <br />
*'''default''' keyword in Interfaces: should be avoided and only used if unavoidable and justified (to prevent unnecessary API break for example)<br />
*'''var''' keyword is forbidden<br />
*'''lambda expressions''' are allowed, but must be commented to ease the understanding<br />
*each file has an header with the EPL licence and your name <br />
*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.<br />
*the version numbers are correcct. see [https://wiki.eclipse.org/Version_Numbering this guide] for more information.<br />
<br />
=== String Externalization/Internalization ===<br />
*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,<br />
<br />
Follow this [[Papyrus_Developer_Guide/Externalize_Strings_In_Java | link]] for a guide on externalization in Eclipse.<br />
<br />
=== Write Documentation for Papyrus ===<br />
Each new contribution must contribute to the documentation (behavior changes or new feature). <br />
The documentation must be splitted in two parts: <br />
*user documentation<br />
*developer documentation<br />
<br />
How to - Related to documentation [[Papyrus Developer Guide/Writing Documentation]]<br />
<br />
=== Plugin Versioning - Deprecated code ===<br />
Using the @Deprecated tag, you must do these things in the same time:<br />
*increase the minor version of the plugin (of course, only if it has not yet be done since the last release)<br />
**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.<br />
* indicate in the comment the plugin version when the class/method became deprecated<br />
* open a bug to remove the deprecated class/method in the next major release<br />
* reference this bug in the comment of the deprecated class/method<br />
* (optional) indicate in the comment in which major release the class/method will be remove<br />
<br />
Add the end, you must have something like that: <br />
<br />
<nowiki><br />
/**<br />
*<br />
* @deprecated since 3.1<br />
* use {@link org.eclipse.papyrus.infra.gmfdiag.common.structure.DiagramStructure} API instead<br />
*<br />
* This class will be removed in Papyrus 5.0, see Bug 541027<br />
*<br />
*<br />
*/<br />
@Deprecated<br />
public abstract class DiagramStructure {<br />
...<br />
}<br />
</nowiki><br />
<br />
=== API ===<br />
* Code of plugins shall be inside internal package<br />
* API shall be public and each classe presence shall be justified by implementation of usecase<br />
* The usecase are store inside the plugin the name of the file '''XXX.usecases.md'''<br />
* The grammar is:<br />
### requirement text <br />
* qualified name of the class<br />
<br />
* See the folowing example<br />
<br />
### The profile validation must be done with a button 'Validate Profile plug-in' on plug-in, in the papyrus developer menu<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.handlers.ValidateProfilePluginHandler<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.testers.ValidateProfilePluginTester<br />
* plugin.xml<br />
### During the validation, a progress monitor must be opened with correct explanations<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.handlers.ValidateProfilePluginHandler<br />
### A checker for the extensions must be implemented<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.internal.checkers.ProfileExtensionsChecker<br />
### A checker for the definition profile must be implemented<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.internal.checkers.ProfileDefinitionChecker<br />
<br />
== Contribute ==<br />
<br />
=== CQs ===<br />
* Remember to check on the current CQs to see if they are still current and that we will not miss any currently required dependencies (e.g. glazed lists in the new orbit or the new apache.common.io dependency) as well as the IPlogs. A quick tutorial on CQs can be found [https://wiki.eclipse.org/Papyrus_Developer_Guide/Contribution_Questionaire here].<br />
<br />
=== Gerrit ===<br />
<br />
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]]<br />
<br />
(For further information, see http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf) <br />
<br />
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;: <br />
<br />
*(1) I, Forename Name, wrote 100% of the code I've provided. <br />
*(2) This code contains no cryptography <br />
*(3) I have the right to contribute the code to Eclipse. <br />
*(4) I contribute the content under the EPL.<br />
<br />
+ Set the field Review to '?'.<br />
<br />
=== Commit message ===<br />
*During the commit&nbsp;: <br />
**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.<br />
<br />
<br />
== Code Reviews ==<br />
<br />
=== What to check before committing a patch ===<br />
<br />
Before commiting a patch, you should verify that the contributor has written the following lines in the comment&nbsp;: <br />
<br />
*(1) I, Forename Name, wrote 100% of the code I've provided. <br />
*(2) This code contains no cryptography <br />
*(3) I have the right to contribute the code to Eclipse. <br />
*(4) I contribute the content under the EPL.<br />
<br />
If not, he must do that before you commit its patch! <br />
<br />
*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;: <br />
**Here is a contribution from one employee of "the name of the company" <br />
**The company has signed a Member Commiter Agreement. <br />
**The contribution does not need a CQ. <br />
**I've committed this contribution. <br />
**Committed revision xxx. <br />
**Set the field iplog to +<br />
<br />
Note&nbsp;: In reality, you should have the autorization of the PMC before doing this commit. <br />
<br />
*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.<br />
<br />
*In all other cases, see http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf<br />
<br />
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/><br />
Here are some guidelines (which may be altered and/or improved) that every reviewer and committer should follow:<br />
* '''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.<br />
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.<br />
/*****************************************************************************<br />
* Copyright (c) 2015, 2018 CEA LIST, Committer Name, and others.<br />
*<br />
* All rights reserved. This program and the accompanying materials<br />
* are made available under the terms of the Eclipse Public License 2.0<br />
* which accompanies this distribution, and is available at<br />
* https://www.eclipse.org/legal/epl-2.0/<br />
*<br />
* SPDX-License-Identifier: EPL-2.0<br />
*<br />
* Contributors:<br />
* CEA LIST - Initial API and implementation<br />
* Committer Name (CEA LIST) committer.name@cea.fr - Bug 492522, Bug XXXXXX<br />
*****************************************************************************/<br />
<br />
###############################################################################<br />
# Copyright (c) 2013, 2018 CEA LIST, Committer Name, and others.<br />
#<br />
# All rights reserved. This program and the accompanying materials<br />
# are made available under the terms of the Eclipse Public License 2.0<br />
# which accompanies this distribution, and is available at<br />
# https://www.eclipse.org/legal/epl-2.0/<br />
#<br />
# SPDX-License-Identifier: EPL-2.0<br />
#<br />
# Contributors:<br />
#<br />
###############################################################################<br />
<br />
* '''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.<br />
* '''Strings''': Verify the Non-NLS markers.<br />
* '''Tags''': (@since plugin-number, ...)<br />
/**<br />
* Constructs an Editor for multiple Integer values.<br />
* The widget is a List, with controls to move values up/down, add values and remove values.<br />
*<br />
* @param parent<br />
* The Composite in which this editor is created<br />
* @param directCreation<br />
* Indicates if the creation and modification are directed.<br />
* @param directCreationWithTreeViewer<br />
* Indicates if the creation and modification are directed on the TreeViewer.<br />
* @param style<br />
* The List's style<br />
*<br />
* @since 3.1<br />
*/<br />
public MultipleIntegerEditor(Composite parent, ...){}<br />
<br />
* '''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.<br />
* '''Reexports''': A contributed code should never introduce any 'hidden' dependencies such as reexporting plugins dependencies.<br />
* '''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).<br />
* '''Attributes''': All attributes, field must be at beginning of the class<br />
* '''Returns and conditions''': You can have as many 'return' statement you need in a method.<br />
<br />
* '''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.<br />
<feature <br />
id="org.eclipse.papyrus.XXXXXXX.feature" <br />
version="2.0.0.qualifier"<br />
label="%featureName" <br />
provider-name="%providerName" <br />
license-feature="org.eclipse.license"<br />
license-feature-version="2.0.0"><br />
<br />
<description><br />
%description<br />
</description><br />
<br />
<copyright><br />
%copyright<br />
</copyright><br />
<br />
<license url="%licenseURL"><br />
%license<br />
</license><br />
<br />
<br />
== Merge ==<br />
Eclipse release calendar is detailled [[Simultaneous_Release|here]]. Each date of releases (M1, M2, M3, RC1, RC2 and GA) for the new Eclipse version is defined in a associated wiki page of the Eclipse version). <br />
<br />
Contributions should be merged before:<br />
*M2+<br />
It is forbidden to modify the GUI. Only important bug fixes should be merged. <br />
Creation of a branch (tag) for the release<br />
*M3+<br />
It is forbidden to modify the features and general architecture.<br />
*RC1+<br />
Its forbidden to merge contribution. Only by the project Chief for critical bugs.</div>Patrick.Tessier.cea.frhttps://wiki.eclipse.org/index.php?title=Papyrus/Papyrus_Developer_Guide/How_To-_Code_Contributing&diff=440629Papyrus/Papyrus Developer Guide/How To- Code Contributing2020-09-10T14:53:02Z<p>Patrick.Tessier.cea.fr: /* Code formatting */</p>
<hr />
<div>__TOC__<br />
<br />
<br />
All papyrus contributors shall follow these rules:<br />
<br />
== Write a Bugzilla task ==<br />
When adding a task to the buzilla, the following grammar should be used: <br />
<br />
*'[' ''Category'' ']' ''NameOfTheTask''<br><br />
<br />
The category helps to filter the bugs for developers. There are already some existing categories: General, XXX Diagram, Common, Property View, etc.<br />
<br />
As a reminder, the lifecycle of bugs is located here: [[Development Resources/HOWTO/Bugzilla Use|Bugzilla Use]]<br />
<br />
*Your contribution shall be associated to a bug refenced in the bugzilla.<br />
*When a bug is opened/resolved/closed the Target Milestone must be filled. For example the bug has been fixed for the service release 3 of oxygen, the target milestone is 3.3.<br />
<br />
<br />
== Write the code ==<br />
<br />
=== Papyrus Plugin Structure ===<br />
<br />
*Papyrus plugin naming scheme and folder structure used to locate and name plugins is described here: [[Papyrus/Papyrus_Developer_Guide/Papyrus_Plugin_Naming_Scheme]]<br />
<br />
*All plug-ins must compile and run against JavaSE-1.8. Papyrus 5.0 must compile against openjdk-11.<br />
*Plug-in provider&nbsp;: ''Eclipse Modeling Project'' <br />
*Version&nbsp;: <br />
***Papyrus adheres to the [[Version Numbering|Eclipse Versioning Guidelines]] for API evolution and other kinds of changes''<br />
*Plug-in name&nbsp;: must end with (Incubation) if version is less than 1.0.0 . If the version is at least 1.0.0, the (Incubation) suffix must be removed.<br />
*Plug-in ID&nbsp;: must start with org.eclipse.papyrus.<br />
*Plug-in dependencies must not be re-exported.<br />
*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"'')<br />
**The Papyrus Developer Tools has 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<br />
*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: <br />
**META-INF/ <br />
**about.html <br />
**icons/, images/, resources/, models/, etc. (All folders containing runtime resources) <br />
**plugin.properties <br />
**plugin.xml <br />
**schema/ <br />
*Do '''not''' include the following files: <br />
**.classpath <br />
**.project <br />
**bin/, src/, src-gen/, custom-src/ <br />
**build.properties <br />
*The ''Source build'' (field src.includes in build.properties) category '''must''' contain the '''about.html''' file: <br />
*It '''must not''' contain the following: <br />
**src/, src-gen/, custom-src/ <br />
**All files and directories are already contained in the "Binary build" category (Except the about.html which must be contained in both Binary and Source builds)<br />
<br />
plugin.xml:<br><br />
[[Image:Papyrus.codestandards.plugin.xml.png]]<br />
<br />
<br />
=== Code formatting ===<br />
Before writing any code you should check that you have the papyrus templates set as your format in your IDE.<br />
These can be [https://wiki.eclipse.org/Papyrus/Papyrus_Developer_Guide#Apply_Papyrus_Configuration_Files retrieved following these steps].<br />
<br />
These could also be retreived and applied from the .settings folder of each plugins. (An example can be found [https://git.eclipse.org/c/papyrus/org.eclipse.papyrus.git/tree/plugins/infra/core/org.eclipse.papyrus.infra.core.log/.settings here])<br />
<br />
=== String Externalization/Internalization ===<br />
*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,<br />
<br />
Follow this [[Papyrus_Developer_Guide/Externalize_Strings_In_Java | link]] for a guide on externalization in Eclipse.<br />
<br />
=== Write Documentation for Papyrus ===<br />
Each new contribution must contribute to the documentation (behavior changes or new feature). <br />
The documentation must be splitted in two parts: <br />
*user documentation<br />
*developer documentation<br />
<br />
How to - Related to documentation [[Papyrus Developer Guide/Writing Documentation]]<br />
<br />
=== Plugin Versioning - Deprecated code ===<br />
Using the @Deprecated tag, you must do these things in the same time:<br />
*increase the minor version of the plugin (of course, only if it has not yet be done since the last release)<br />
**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.<br />
* indicate in the comment the plugin version when the class/method became deprecated<br />
* open a bug to remove the deprecated class/method in the next major release<br />
* reference this bug in the comment of the deprecated class/method<br />
* (optional) indicate in the comment in which major release the class/method will be remove<br />
<br />
Add the end, you must have something like that: <br />
<br />
<nowiki><br />
/**<br />
*<br />
* @deprecated since 3.1<br />
* use {@link org.eclipse.papyrus.infra.gmfdiag.common.structure.DiagramStructure} API instead<br />
*<br />
* This class will be removed in Papyrus 5.0, see Bug 541027<br />
*<br />
*<br />
*/<br />
@Deprecated<br />
public abstract class DiagramStructure {<br />
...<br />
}<br />
</nowiki><br />
<br />
=== API ===<br />
* Code of plugins shall be inside internal package<br />
* API shall be public and each classe presence shall be justified by implementation of usecase<br />
* The usecase are store inside the plugin the name of the file '''XXX.usecases.md'''<br />
* The grammar is:<br />
### requirement text <br />
* qualified name of the class<br />
<br />
* See the folowing example<br />
<br />
### The profile validation must be done with a button 'Validate Profile plug-in' on plug-in, in the papyrus developer menu<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.handlers.ValidateProfilePluginHandler<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.testers.ValidateProfilePluginTester<br />
* plugin.xml<br />
### During the validation, a progress monitor must be opened with correct explanations<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.handlers.ValidateProfilePluginHandler<br />
### A checker for the extensions must be implemented<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.internal.checkers.ProfileExtensionsChecker<br />
### A checker for the definition profile must be implemented<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.internal.checkers.ProfileDefinitionChecker<br />
<br />
== Contribute ==<br />
<br />
=== CQs ===<br />
* Remember to check on the current CQs to see if they are still current and that we will not miss any currently required dependencies (e.g. glazed lists in the new orbit or the new apache.common.io dependency) as well as the IPlogs. A quick tutorial on CQs can be found [https://wiki.eclipse.org/Papyrus_Developer_Guide/Contribution_Questionaire here].<br />
<br />
=== Gerrit ===<br />
<br />
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]]<br />
<br />
(For further information, see http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf) <br />
<br />
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;: <br />
<br />
*(1) I, Forename Name, wrote 100% of the code I've provided. <br />
*(2) This code contains no cryptography <br />
*(3) I have the right to contribute the code to Eclipse. <br />
*(4) I contribute the content under the EPL.<br />
<br />
+ Set the field Review to '?'.<br />
<br />
=== Commit message ===<br />
*During the commit&nbsp;: <br />
**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.<br />
<br />
<br />
== Code Reviews ==<br />
<br />
=== What to check before committing a patch ===<br />
<br />
Before commiting a patch, you should verify that the contributor has written the following lines in the comment&nbsp;: <br />
<br />
*(1) I, Forename Name, wrote 100% of the code I've provided. <br />
*(2) This code contains no cryptography <br />
*(3) I have the right to contribute the code to Eclipse. <br />
*(4) I contribute the content under the EPL.<br />
<br />
If not, he must do that before you commit its patch! <br />
<br />
*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;: <br />
**Here is a contribution from one employee of "the name of the company" <br />
**The company has signed a Member Commiter Agreement. <br />
**The contribution does not need a CQ. <br />
**I've committed this contribution. <br />
**Committed revision xxx. <br />
**Set the field iplog to +<br />
<br />
Note&nbsp;: In reality, you should have the autorization of the PMC before doing this commit. <br />
<br />
*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.<br />
<br />
*In all other cases, see http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf<br />
<br />
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/><br />
Here are some guidelines (which may be altered and/or improved) that every reviewer and committer should follow:<br />
* '''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.<br />
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.<br />
/*****************************************************************************<br />
* Copyright (c) 2015, 2018 CEA LIST, Committer Name, and others.<br />
*<br />
* All rights reserved. This program and the accompanying materials<br />
* are made available under the terms of the Eclipse Public License 2.0<br />
* which accompanies this distribution, and is available at<br />
* https://www.eclipse.org/legal/epl-2.0/<br />
*<br />
* SPDX-License-Identifier: EPL-2.0<br />
*<br />
* Contributors:<br />
* CEA LIST - Initial API and implementation<br />
* Committer Name (CEA LIST) committer.name@cea.fr - Bug 492522, Bug XXXXXX<br />
*****************************************************************************/<br />
<br />
###############################################################################<br />
# Copyright (c) 2013, 2018 CEA LIST, Committer Name, and others.<br />
#<br />
# All rights reserved. This program and the accompanying materials<br />
# are made available under the terms of the Eclipse Public License 2.0<br />
# which accompanies this distribution, and is available at<br />
# https://www.eclipse.org/legal/epl-2.0/<br />
#<br />
# SPDX-License-Identifier: EPL-2.0<br />
#<br />
# Contributors:<br />
#<br />
###############################################################################<br />
<br />
* '''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.<br />
* '''Strings''': Verify the Non-NLS markers.<br />
* '''Tags''': (@since plugin-number, ...)<br />
/**<br />
* Constructs an Editor for multiple Integer values.<br />
* The widget is a List, with controls to move values up/down, add values and remove values.<br />
*<br />
* @param parent<br />
* The Composite in which this editor is created<br />
* @param directCreation<br />
* Indicates if the creation and modification are directed.<br />
* @param directCreationWithTreeViewer<br />
* Indicates if the creation and modification are directed on the TreeViewer.<br />
* @param style<br />
* The List's style<br />
*<br />
* @since 3.1<br />
*/<br />
public MultipleIntegerEditor(Composite parent, ...){}<br />
<br />
* '''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.<br />
* '''Reexports''': A contributed code should never introduce any 'hidden' dependencies such as reexporting plugins dependencies.<br />
* '''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).<br />
* '''Attributes''': All attributes, field must be at beginning of the class<br />
* '''Returns and conditions''': You can have as many 'return' statement you need in a method.<br />
<br />
* '''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.<br />
<feature <br />
id="org.eclipse.papyrus.XXXXXXX.feature" <br />
version="2.0.0.qualifier"<br />
label="%featureName" <br />
provider-name="%providerName" <br />
license-feature="org.eclipse.license"<br />
license-feature-version="2.0.0"><br />
<br />
<description><br />
%description<br />
</description><br />
<br />
<copyright><br />
%copyright<br />
</copyright><br />
<br />
<license url="%licenseURL"><br />
%license<br />
</license><br />
<br />
<br />
== Merge ==<br />
Eclipse release calendar is detailled [[Simultaneous_Release|here]]. Each date of releases (M1, M2, M3, RC1, RC2 and GA) for the new Eclipse version is defined in a associated wiki page of the Eclipse version). <br />
<br />
Contributions should be merged before:<br />
*M2+<br />
It is forbidden to modify the GUI. Only important bug fixes should be merged. <br />
Creation of a branch (tag) for the release<br />
*M3+<br />
It is forbidden to modify the features and general architecture.<br />
*RC1+<br />
Its forbidden to merge contribution. Only by the project Chief for critical bugs.</div>Patrick.Tessier.cea.frhttps://wiki.eclipse.org/index.php?title=Papyrus/Papyrus_Developer_Guide/How_To-_Code_Contributing&diff=440628Papyrus/Papyrus Developer Guide/How To- Code Contributing2020-09-10T14:52:42Z<p>Patrick.Tessier.cea.fr: /* Code formatting */</p>
<hr />
<div>__TOC__<br />
<br />
<br />
All papyrus contributors shall follow these rules:<br />
<br />
== Write a Bugzilla task ==<br />
When adding a task to the buzilla, the following grammar should be used: <br />
<br />
*'[' ''Category'' ']' ''NameOfTheTask''<br><br />
<br />
The category helps to filter the bugs for developers. There are already some existing categories: General, XXX Diagram, Common, Property View, etc.<br />
<br />
As a reminder, the lifecycle of bugs is located here: [[Development Resources/HOWTO/Bugzilla Use|Bugzilla Use]]<br />
<br />
*Your contribution shall be associated to a bug refenced in the bugzilla.<br />
*When a bug is opened/resolved/closed the Target Milestone must be filled. For example the bug has been fixed for the service release 3 of oxygen, the target milestone is 3.3.<br />
<br />
<br />
== Write the code ==<br />
<br />
=== Papyrus Plugin Structure ===<br />
<br />
*Papyrus plugin naming scheme and folder structure used to locate and name plugins is described here: [[Papyrus/Papyrus_Developer_Guide/Papyrus_Plugin_Naming_Scheme]]<br />
<br />
*All plug-ins must compile and run against JavaSE-1.8. Papyrus 5.0 must compile against openjdk-11.<br />
*Plug-in provider&nbsp;: ''Eclipse Modeling Project'' <br />
*Version&nbsp;: <br />
***Papyrus adheres to the [[Version Numbering|Eclipse Versioning Guidelines]] for API evolution and other kinds of changes''<br />
*Plug-in name&nbsp;: must end with (Incubation) if version is less than 1.0.0 . If the version is at least 1.0.0, the (Incubation) suffix must be removed.<br />
*Plug-in ID&nbsp;: must start with org.eclipse.papyrus.<br />
*Plug-in dependencies must not be re-exported.<br />
*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"'')<br />
**The Papyrus Developer Tools has 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<br />
*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: <br />
**META-INF/ <br />
**about.html <br />
**icons/, images/, resources/, models/, etc. (All folders containing runtime resources) <br />
**plugin.properties <br />
**plugin.xml <br />
**schema/ <br />
*Do '''not''' include the following files: <br />
**.classpath <br />
**.project <br />
**bin/, src/, src-gen/, custom-src/ <br />
**build.properties <br />
*The ''Source build'' (field src.includes in build.properties) category '''must''' contain the '''about.html''' file: <br />
*It '''must not''' contain the following: <br />
**src/, src-gen/, custom-src/ <br />
**All files and directories are already contained in the "Binary build" category (Except the about.html which must be contained in both Binary and Source builds)<br />
<br />
plugin.xml:<br><br />
[[Image:Papyrus.codestandards.plugin.xml.png]]<br />
<br />
<br />
=== Code formatting ===<br />
Before writing any code you should check that you have the papyrus templates set as your format in your IDE.<br />
These can be [https://wiki.eclipse.org/Papyrus/Papyrus_Developer_Guide#Apply_Papyrus_Configuration_Files retrieved following these steps].<br />
<br />
These could also be retreived and applied from the .settings folder of each plugins. (An example can be found [https://git.eclipse.org/c/papyrus/org.eclipse.papyrus.git/tree/plugins/infra/core/org.eclipse.papyrus.infra.core.log/.settings here]<br />
<br />
=== String Externalization/Internalization ===<br />
*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,<br />
<br />
Follow this [[Papyrus_Developer_Guide/Externalize_Strings_In_Java | link]] for a guide on externalization in Eclipse.<br />
<br />
=== Write Documentation for Papyrus ===<br />
Each new contribution must contribute to the documentation (behavior changes or new feature). <br />
The documentation must be splitted in two parts: <br />
*user documentation<br />
*developer documentation<br />
<br />
How to - Related to documentation [[Papyrus Developer Guide/Writing Documentation]]<br />
<br />
=== Plugin Versioning - Deprecated code ===<br />
Using the @Deprecated tag, you must do these things in the same time:<br />
*increase the minor version of the plugin (of course, only if it has not yet be done since the last release)<br />
**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.<br />
* indicate in the comment the plugin version when the class/method became deprecated<br />
* open a bug to remove the deprecated class/method in the next major release<br />
* reference this bug in the comment of the deprecated class/method<br />
* (optional) indicate in the comment in which major release the class/method will be remove<br />
<br />
Add the end, you must have something like that: <br />
<br />
<nowiki><br />
/**<br />
*<br />
* @deprecated since 3.1<br />
* use {@link org.eclipse.papyrus.infra.gmfdiag.common.structure.DiagramStructure} API instead<br />
*<br />
* This class will be removed in Papyrus 5.0, see Bug 541027<br />
*<br />
*<br />
*/<br />
@Deprecated<br />
public abstract class DiagramStructure {<br />
...<br />
}<br />
</nowiki><br />
<br />
=== API ===<br />
* Code of plugins shall be inside internal package<br />
* API shall be public and each classe presence shall be justified by implementation of usecase<br />
* The usecase are store inside the plugin the name of the file '''XXX.usecases.md'''<br />
* The grammar is:<br />
### requirement text <br />
* qualified name of the class<br />
<br />
* See the folowing example<br />
<br />
### The profile validation must be done with a button 'Validate Profile plug-in' on plug-in, in the papyrus developer menu<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.handlers.ValidateProfilePluginHandler<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.testers.ValidateProfilePluginTester<br />
* plugin.xml<br />
### During the validation, a progress monitor must be opened with correct explanations<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.handlers.ValidateProfilePluginHandler<br />
### A checker for the extensions must be implemented<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.internal.checkers.ProfileExtensionsChecker<br />
### A checker for the definition profile must be implemented<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.internal.checkers.ProfileDefinitionChecker<br />
<br />
== Contribute ==<br />
<br />
=== CQs ===<br />
* Remember to check on the current CQs to see if they are still current and that we will not miss any currently required dependencies (e.g. glazed lists in the new orbit or the new apache.common.io dependency) as well as the IPlogs. A quick tutorial on CQs can be found [https://wiki.eclipse.org/Papyrus_Developer_Guide/Contribution_Questionaire here].<br />
<br />
=== Gerrit ===<br />
<br />
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]]<br />
<br />
(For further information, see http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf) <br />
<br />
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;: <br />
<br />
*(1) I, Forename Name, wrote 100% of the code I've provided. <br />
*(2) This code contains no cryptography <br />
*(3) I have the right to contribute the code to Eclipse. <br />
*(4) I contribute the content under the EPL.<br />
<br />
+ Set the field Review to '?'.<br />
<br />
=== Commit message ===<br />
*During the commit&nbsp;: <br />
**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.<br />
<br />
<br />
== Code Reviews ==<br />
<br />
=== What to check before committing a patch ===<br />
<br />
Before commiting a patch, you should verify that the contributor has written the following lines in the comment&nbsp;: <br />
<br />
*(1) I, Forename Name, wrote 100% of the code I've provided. <br />
*(2) This code contains no cryptography <br />
*(3) I have the right to contribute the code to Eclipse. <br />
*(4) I contribute the content under the EPL.<br />
<br />
If not, he must do that before you commit its patch! <br />
<br />
*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;: <br />
**Here is a contribution from one employee of "the name of the company" <br />
**The company has signed a Member Commiter Agreement. <br />
**The contribution does not need a CQ. <br />
**I've committed this contribution. <br />
**Committed revision xxx. <br />
**Set the field iplog to +<br />
<br />
Note&nbsp;: In reality, you should have the autorization of the PMC before doing this commit. <br />
<br />
*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.<br />
<br />
*In all other cases, see http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf<br />
<br />
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/><br />
Here are some guidelines (which may be altered and/or improved) that every reviewer and committer should follow:<br />
* '''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.<br />
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.<br />
/*****************************************************************************<br />
* Copyright (c) 2015, 2018 CEA LIST, Committer Name, and others.<br />
*<br />
* All rights reserved. This program and the accompanying materials<br />
* are made available under the terms of the Eclipse Public License 2.0<br />
* which accompanies this distribution, and is available at<br />
* https://www.eclipse.org/legal/epl-2.0/<br />
*<br />
* SPDX-License-Identifier: EPL-2.0<br />
*<br />
* Contributors:<br />
* CEA LIST - Initial API and implementation<br />
* Committer Name (CEA LIST) committer.name@cea.fr - Bug 492522, Bug XXXXXX<br />
*****************************************************************************/<br />
<br />
###############################################################################<br />
# Copyright (c) 2013, 2018 CEA LIST, Committer Name, and others.<br />
#<br />
# All rights reserved. This program and the accompanying materials<br />
# are made available under the terms of the Eclipse Public License 2.0<br />
# which accompanies this distribution, and is available at<br />
# https://www.eclipse.org/legal/epl-2.0/<br />
#<br />
# SPDX-License-Identifier: EPL-2.0<br />
#<br />
# Contributors:<br />
#<br />
###############################################################################<br />
<br />
* '''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.<br />
* '''Strings''': Verify the Non-NLS markers.<br />
* '''Tags''': (@since plugin-number, ...)<br />
/**<br />
* Constructs an Editor for multiple Integer values.<br />
* The widget is a List, with controls to move values up/down, add values and remove values.<br />
*<br />
* @param parent<br />
* The Composite in which this editor is created<br />
* @param directCreation<br />
* Indicates if the creation and modification are directed.<br />
* @param directCreationWithTreeViewer<br />
* Indicates if the creation and modification are directed on the TreeViewer.<br />
* @param style<br />
* The List's style<br />
*<br />
* @since 3.1<br />
*/<br />
public MultipleIntegerEditor(Composite parent, ...){}<br />
<br />
* '''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.<br />
* '''Reexports''': A contributed code should never introduce any 'hidden' dependencies such as reexporting plugins dependencies.<br />
* '''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).<br />
* '''Attributes''': All attributes, field must be at beginning of the class<br />
* '''Returns and conditions''': You can have as many 'return' statement you need in a method.<br />
<br />
* '''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.<br />
<feature <br />
id="org.eclipse.papyrus.XXXXXXX.feature" <br />
version="2.0.0.qualifier"<br />
label="%featureName" <br />
provider-name="%providerName" <br />
license-feature="org.eclipse.license"<br />
license-feature-version="2.0.0"><br />
<br />
<description><br />
%description<br />
</description><br />
<br />
<copyright><br />
%copyright<br />
</copyright><br />
<br />
<license url="%licenseURL"><br />
%license<br />
</license><br />
<br />
<br />
== Merge ==<br />
Eclipse release calendar is detailled [[Simultaneous_Release|here]]. Each date of releases (M1, M2, M3, RC1, RC2 and GA) for the new Eclipse version is defined in a associated wiki page of the Eclipse version). <br />
<br />
Contributions should be merged before:<br />
*M2+<br />
It is forbidden to modify the GUI. Only important bug fixes should be merged. <br />
Creation of a branch (tag) for the release<br />
*M3+<br />
It is forbidden to modify the features and general architecture.<br />
*RC1+<br />
Its forbidden to merge contribution. Only by the project Chief for critical bugs.</div>Patrick.Tessier.cea.frhttps://wiki.eclipse.org/index.php?title=Papyrus/Papyrus_Developer_Guide/How_To-_Code_Contributing&diff=440627Papyrus/Papyrus Developer Guide/How To- Code Contributing2020-09-10T14:46:55Z<p>Patrick.Tessier.cea.fr: /* Code formatting */</p>
<hr />
<div>__TOC__<br />
<br />
<br />
All papyrus contributors shall follow these rules:<br />
<br />
== Write a Bugzilla task ==<br />
When adding a task to the buzilla, the following grammar should be used: <br />
<br />
*'[' ''Category'' ']' ''NameOfTheTask''<br><br />
<br />
The category helps to filter the bugs for developers. There are already some existing categories: General, XXX Diagram, Common, Property View, etc.<br />
<br />
As a reminder, the lifecycle of bugs is located here: [[Development Resources/HOWTO/Bugzilla Use|Bugzilla Use]]<br />
<br />
*Your contribution shall be associated to a bug refenced in the bugzilla.<br />
*When a bug is opened/resolved/closed the Target Milestone must be filled. For example the bug has been fixed for the service release 3 of oxygen, the target milestone is 3.3.<br />
<br />
<br />
== Write the code ==<br />
<br />
=== Papyrus Plugin Structure ===<br />
<br />
*Papyrus plugin naming scheme and folder structure used to locate and name plugins is described here: [[Papyrus/Papyrus_Developer_Guide/Papyrus_Plugin_Naming_Scheme]]<br />
<br />
*All plug-ins must compile and run against JavaSE-1.8. Papyrus 5.0 must compile against openjdk-11.<br />
*Plug-in provider&nbsp;: ''Eclipse Modeling Project'' <br />
*Version&nbsp;: <br />
***Papyrus adheres to the [[Version Numbering|Eclipse Versioning Guidelines]] for API evolution and other kinds of changes''<br />
*Plug-in name&nbsp;: must end with (Incubation) if version is less than 1.0.0 . If the version is at least 1.0.0, the (Incubation) suffix must be removed.<br />
*Plug-in ID&nbsp;: must start with org.eclipse.papyrus.<br />
*Plug-in dependencies must not be re-exported.<br />
*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"'')<br />
**The Papyrus Developer Tools has 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<br />
*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: <br />
**META-INF/ <br />
**about.html <br />
**icons/, images/, resources/, models/, etc. (All folders containing runtime resources) <br />
**plugin.properties <br />
**plugin.xml <br />
**schema/ <br />
*Do '''not''' include the following files: <br />
**.classpath <br />
**.project <br />
**bin/, src/, src-gen/, custom-src/ <br />
**build.properties <br />
*The ''Source build'' (field src.includes in build.properties) category '''must''' contain the '''about.html''' file: <br />
*It '''must not''' contain the following: <br />
**src/, src-gen/, custom-src/ <br />
**All files and directories are already contained in the "Binary build" category (Except the about.html which must be contained in both Binary and Source builds)<br />
<br />
plugin.xml:<br><br />
[[Image:Papyrus.codestandards.plugin.xml.png]]<br />
<br />
<br />
=== Code formatting ===<br />
Before writing any code you should check that you have the papyrus templates set as your format in your IDE.<br />
These can be [https://wiki.eclipse.org/Papyrus/Papyrus_Developer_Guide#Apply_Papyrus_Configuration_Files retrieved following these steps].<br />
<br />
=== String Externalization/Internalization ===<br />
*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,<br />
<br />
Follow this [[Papyrus_Developer_Guide/Externalize_Strings_In_Java | link]] for a guide on externalization in Eclipse.<br />
<br />
=== Write Documentation for Papyrus ===<br />
Each new contribution must contribute to the documentation (behavior changes or new feature). <br />
The documentation must be splitted in two parts: <br />
*user documentation<br />
*developer documentation<br />
<br />
How to - Related to documentation [[Papyrus Developer Guide/Writing Documentation]]<br />
<br />
=== Plugin Versioning - Deprecated code ===<br />
Using the @Deprecated tag, you must do these things in the same time:<br />
*increase the minor version of the plugin (of course, only if it has not yet be done since the last release)<br />
**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.<br />
* indicate in the comment the plugin version when the class/method became deprecated<br />
* open a bug to remove the deprecated class/method in the next major release<br />
* reference this bug in the comment of the deprecated class/method<br />
* (optional) indicate in the comment in which major release the class/method will be remove<br />
<br />
Add the end, you must have something like that: <br />
<br />
<nowiki><br />
/**<br />
*<br />
* @deprecated since 3.1<br />
* use {@link org.eclipse.papyrus.infra.gmfdiag.common.structure.DiagramStructure} API instead<br />
*<br />
* This class will be removed in Papyrus 5.0, see Bug 541027<br />
*<br />
*<br />
*/<br />
@Deprecated<br />
public abstract class DiagramStructure {<br />
...<br />
}<br />
</nowiki><br />
<br />
=== API ===<br />
* Code of plugins shall be inside internal package<br />
* API shall be public and each classe presence shall be justified by implementation of usecase<br />
* The usecase are store inside the plugin the name of the file '''XXX.usecases.md'''<br />
* The grammar is:<br />
### requirement text <br />
* qualified name of the class<br />
<br />
* See the folowing example<br />
<br />
### The profile validation must be done with a button 'Validate Profile plug-in' on plug-in, in the papyrus developer menu<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.handlers.ValidateProfilePluginHandler<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.testers.ValidateProfilePluginTester<br />
* plugin.xml<br />
### During the validation, a progress monitor must be opened with correct explanations<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.handlers.ValidateProfilePluginHandler<br />
### A checker for the extensions must be implemented<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.internal.checkers.ProfileExtensionsChecker<br />
### A checker for the definition profile must be implemented<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.internal.checkers.ProfileDefinitionChecker<br />
<br />
== Contribute ==<br />
<br />
=== CQs ===<br />
* Remember to check on the current CQs to see if they are still current and that we will not miss any currently required dependencies (e.g. glazed lists in the new orbit or the new apache.common.io dependency) as well as the IPlogs. A quick tutorial on CQs can be found [https://wiki.eclipse.org/Papyrus_Developer_Guide/Contribution_Questionaire here].<br />
<br />
=== Gerrit ===<br />
<br />
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]]<br />
<br />
(For further information, see http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf) <br />
<br />
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;: <br />
<br />
*(1) I, Forename Name, wrote 100% of the code I've provided. <br />
*(2) This code contains no cryptography <br />
*(3) I have the right to contribute the code to Eclipse. <br />
*(4) I contribute the content under the EPL.<br />
<br />
+ Set the field Review to '?'.<br />
<br />
=== Commit message ===<br />
*During the commit&nbsp;: <br />
**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.<br />
<br />
<br />
== Code Reviews ==<br />
<br />
=== What to check before committing a patch ===<br />
<br />
Before commiting a patch, you should verify that the contributor has written the following lines in the comment&nbsp;: <br />
<br />
*(1) I, Forename Name, wrote 100% of the code I've provided. <br />
*(2) This code contains no cryptography <br />
*(3) I have the right to contribute the code to Eclipse. <br />
*(4) I contribute the content under the EPL.<br />
<br />
If not, he must do that before you commit its patch! <br />
<br />
*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;: <br />
**Here is a contribution from one employee of "the name of the company" <br />
**The company has signed a Member Commiter Agreement. <br />
**The contribution does not need a CQ. <br />
**I've committed this contribution. <br />
**Committed revision xxx. <br />
**Set the field iplog to +<br />
<br />
Note&nbsp;: In reality, you should have the autorization of the PMC before doing this commit. <br />
<br />
*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.<br />
<br />
*In all other cases, see http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf<br />
<br />
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/><br />
Here are some guidelines (which may be altered and/or improved) that every reviewer and committer should follow:<br />
* '''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.<br />
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.<br />
/*****************************************************************************<br />
* Copyright (c) 2015, 2018 CEA LIST, Committer Name, and others.<br />
*<br />
* All rights reserved. This program and the accompanying materials<br />
* are made available under the terms of the Eclipse Public License 2.0<br />
* which accompanies this distribution, and is available at<br />
* https://www.eclipse.org/legal/epl-2.0/<br />
*<br />
* SPDX-License-Identifier: EPL-2.0<br />
*<br />
* Contributors:<br />
* CEA LIST - Initial API and implementation<br />
* Committer Name (CEA LIST) committer.name@cea.fr - Bug 492522, Bug XXXXXX<br />
*****************************************************************************/<br />
<br />
###############################################################################<br />
# Copyright (c) 2013, 2018 CEA LIST, Committer Name, and others.<br />
#<br />
# All rights reserved. This program and the accompanying materials<br />
# are made available under the terms of the Eclipse Public License 2.0<br />
# which accompanies this distribution, and is available at<br />
# https://www.eclipse.org/legal/epl-2.0/<br />
#<br />
# SPDX-License-Identifier: EPL-2.0<br />
#<br />
# Contributors:<br />
#<br />
###############################################################################<br />
<br />
* '''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.<br />
* '''Strings''': Verify the Non-NLS markers.<br />
* '''Tags''': (@since plugin-number, ...)<br />
/**<br />
* Constructs an Editor for multiple Integer values.<br />
* The widget is a List, with controls to move values up/down, add values and remove values.<br />
*<br />
* @param parent<br />
* The Composite in which this editor is created<br />
* @param directCreation<br />
* Indicates if the creation and modification are directed.<br />
* @param directCreationWithTreeViewer<br />
* Indicates if the creation and modification are directed on the TreeViewer.<br />
* @param style<br />
* The List's style<br />
*<br />
* @since 3.1<br />
*/<br />
public MultipleIntegerEditor(Composite parent, ...){}<br />
<br />
* '''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.<br />
* '''Reexports''': A contributed code should never introduce any 'hidden' dependencies such as reexporting plugins dependencies.<br />
* '''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).<br />
* '''Attributes''': All attributes, field must be at beginning of the class<br />
* '''Returns and conditions''': You can have as many 'return' statement you need in a method.<br />
<br />
* '''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.<br />
<feature <br />
id="org.eclipse.papyrus.XXXXXXX.feature" <br />
version="2.0.0.qualifier"<br />
label="%featureName" <br />
provider-name="%providerName" <br />
license-feature="org.eclipse.license"<br />
license-feature-version="2.0.0"><br />
<br />
<description><br />
%description<br />
</description><br />
<br />
<copyright><br />
%copyright<br />
</copyright><br />
<br />
<license url="%licenseURL"><br />
%license<br />
</license><br />
<br />
<br />
== Merge ==<br />
Eclipse release calendar is detailled [[Simultaneous_Release|here]]. Each date of releases (M1, M2, M3, RC1, RC2 and GA) for the new Eclipse version is defined in a associated wiki page of the Eclipse version). <br />
<br />
Contributions should be merged before:<br />
*M2+<br />
It is forbidden to modify the GUI. Only important bug fixes should be merged. <br />
Creation of a branch (tag) for the release<br />
*M3+<br />
It is forbidden to modify the features and general architecture.<br />
*RC1+<br />
Its forbidden to merge contribution. Only by the project Chief for critical bugs.</div>Patrick.Tessier.cea.frhttps://wiki.eclipse.org/index.php?title=Papyrus/Papyrus_Developer_Guide/How_To-_Code_Contributing&diff=440626Papyrus/Papyrus Developer Guide/How To- Code Contributing2020-09-10T14:42:42Z<p>Patrick.Tessier.cea.fr: /* Code formatting */</p>
<hr />
<div>__TOC__<br />
<br />
<br />
All papyrus contributors shall follow these rules:<br />
<br />
== Write a Bugzilla task ==<br />
When adding a task to the buzilla, the following grammar should be used: <br />
<br />
*'[' ''Category'' ']' ''NameOfTheTask''<br><br />
<br />
The category helps to filter the bugs for developers. There are already some existing categories: General, XXX Diagram, Common, Property View, etc.<br />
<br />
As a reminder, the lifecycle of bugs is located here: [[Development Resources/HOWTO/Bugzilla Use|Bugzilla Use]]<br />
<br />
*Your contribution shall be associated to a bug refenced in the bugzilla.<br />
*When a bug is opened/resolved/closed the Target Milestone must be filled. For example the bug has been fixed for the service release 3 of oxygen, the target milestone is 3.3.<br />
<br />
<br />
== Write the code ==<br />
<br />
=== Papyrus Plugin Structure ===<br />
<br />
*Papyrus plugin naming scheme and folder structure used to locate and name plugins is described here: [[Papyrus/Papyrus_Developer_Guide/Papyrus_Plugin_Naming_Scheme]]<br />
<br />
*All plug-ins must compile and run against JavaSE-1.8. Papyrus 5.0 must compile against openjdk-11.<br />
*Plug-in provider&nbsp;: ''Eclipse Modeling Project'' <br />
*Version&nbsp;: <br />
***Papyrus adheres to the [[Version Numbering|Eclipse Versioning Guidelines]] for API evolution and other kinds of changes''<br />
*Plug-in name&nbsp;: must end with (Incubation) if version is less than 1.0.0 . If the version is at least 1.0.0, the (Incubation) suffix must be removed.<br />
*Plug-in ID&nbsp;: must start with org.eclipse.papyrus.<br />
*Plug-in dependencies must not be re-exported.<br />
*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"'')<br />
**The Papyrus Developer Tools has 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<br />
*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: <br />
**META-INF/ <br />
**about.html <br />
**icons/, images/, resources/, models/, etc. (All folders containing runtime resources) <br />
**plugin.properties <br />
**plugin.xml <br />
**schema/ <br />
*Do '''not''' include the following files: <br />
**.classpath <br />
**.project <br />
**bin/, src/, src-gen/, custom-src/ <br />
**build.properties <br />
*The ''Source build'' (field src.includes in build.properties) category '''must''' contain the '''about.html''' file: <br />
*It '''must not''' contain the following: <br />
**src/, src-gen/, custom-src/ <br />
**All files and directories are already contained in the "Binary build" category (Except the about.html which must be contained in both Binary and Source builds)<br />
<br />
plugin.xml:<br><br />
[[Image:Papyrus.codestandards.plugin.xml.png]]<br />
<br />
<br />
=== Code formatting ===<br />
Before writing any code you should check that you have the papyrus templates set as your format in your IDE.<br />
These can be [https://wiki.eclipse.org/Papyrus/Papyrus_Developer_Guide#Apply_Papyrus_Configuration_Files retrieved following these steps].<br />
<br />
<br />
Before committing, you should verify these items&nbsp;: <br />
*'''default''' keyword in Interfaces: should be avoided and only used if unavoidable and justified (to prevent unnecessary API break for example)<br />
*'''var''' keyword is forbidden<br />
*'''lambda expressions''' are allowed, but must be commented to ease the understanding<br />
*each file has an header with the EPL licence and your name <br />
*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.<br />
*the version numbers are correcct. see [https://wiki.eclipse.org/Version_Numbering this guide] for more information.<br />
<br />
=== String Externalization/Internalization ===<br />
*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,<br />
<br />
Follow this [[Papyrus_Developer_Guide/Externalize_Strings_In_Java | link]] for a guide on externalization in Eclipse.<br />
<br />
=== Write Documentation for Papyrus ===<br />
Each new contribution must contribute to the documentation (behavior changes or new feature). <br />
The documentation must be splitted in two parts: <br />
*user documentation<br />
*developer documentation<br />
<br />
How to - Related to documentation [[Papyrus Developer Guide/Writing Documentation]]<br />
<br />
=== Plugin Versioning - Deprecated code ===<br />
Using the @Deprecated tag, you must do these things in the same time:<br />
*increase the minor version of the plugin (of course, only if it has not yet be done since the last release)<br />
**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.<br />
* indicate in the comment the plugin version when the class/method became deprecated<br />
* open a bug to remove the deprecated class/method in the next major release<br />
* reference this bug in the comment of the deprecated class/method<br />
* (optional) indicate in the comment in which major release the class/method will be remove<br />
<br />
Add the end, you must have something like that: <br />
<br />
<nowiki><br />
/**<br />
*<br />
* @deprecated since 3.1<br />
* use {@link org.eclipse.papyrus.infra.gmfdiag.common.structure.DiagramStructure} API instead<br />
*<br />
* This class will be removed in Papyrus 5.0, see Bug 541027<br />
*<br />
*<br />
*/<br />
@Deprecated<br />
public abstract class DiagramStructure {<br />
...<br />
}<br />
</nowiki><br />
<br />
=== API ===<br />
* Code of plugins shall be inside internal package<br />
* API shall be public and each classe presence shall be justified by implementation of usecase<br />
* The usecase are store inside the plugin the name of the file '''XXX.usecases.md'''<br />
* The grammar is:<br />
### requirement text <br />
* qualified name of the class<br />
<br />
* See the folowing example<br />
<br />
### The profile validation must be done with a button 'Validate Profile plug-in' on plug-in, in the papyrus developer menu<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.handlers.ValidateProfilePluginHandler<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.testers.ValidateProfilePluginTester<br />
* plugin.xml<br />
### During the validation, a progress monitor must be opened with correct explanations<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.handlers.ValidateProfilePluginHandler<br />
### A checker for the extensions must be implemented<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.internal.checkers.ProfileExtensionsChecker<br />
### A checker for the definition profile must be implemented<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.internal.checkers.ProfileDefinitionChecker<br />
<br />
== Contribute ==<br />
<br />
=== CQs ===<br />
* Remember to check on the current CQs to see if they are still current and that we will not miss any currently required dependencies (e.g. glazed lists in the new orbit or the new apache.common.io dependency) as well as the IPlogs. A quick tutorial on CQs can be found [https://wiki.eclipse.org/Papyrus_Developer_Guide/Contribution_Questionaire here].<br />
<br />
=== Gerrit ===<br />
<br />
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]]<br />
<br />
(For further information, see http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf) <br />
<br />
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;: <br />
<br />
*(1) I, Forename Name, wrote 100% of the code I've provided. <br />
*(2) This code contains no cryptography <br />
*(3) I have the right to contribute the code to Eclipse. <br />
*(4) I contribute the content under the EPL.<br />
<br />
+ Set the field Review to '?'.<br />
<br />
=== Commit message ===<br />
*During the commit&nbsp;: <br />
**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.<br />
<br />
<br />
== Code Reviews ==<br />
<br />
=== What to check before committing a patch ===<br />
<br />
Before commiting a patch, you should verify that the contributor has written the following lines in the comment&nbsp;: <br />
<br />
*(1) I, Forename Name, wrote 100% of the code I've provided. <br />
*(2) This code contains no cryptography <br />
*(3) I have the right to contribute the code to Eclipse. <br />
*(4) I contribute the content under the EPL.<br />
<br />
If not, he must do that before you commit its patch! <br />
<br />
*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;: <br />
**Here is a contribution from one employee of "the name of the company" <br />
**The company has signed a Member Commiter Agreement. <br />
**The contribution does not need a CQ. <br />
**I've committed this contribution. <br />
**Committed revision xxx. <br />
**Set the field iplog to +<br />
<br />
Note&nbsp;: In reality, you should have the autorization of the PMC before doing this commit. <br />
<br />
*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.<br />
<br />
*In all other cases, see http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf<br />
<br />
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/><br />
Here are some guidelines (which may be altered and/or improved) that every reviewer and committer should follow:<br />
* '''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.<br />
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.<br />
/*****************************************************************************<br />
* Copyright (c) 2015, 2018 CEA LIST, Committer Name, and others.<br />
*<br />
* All rights reserved. This program and the accompanying materials<br />
* are made available under the terms of the Eclipse Public License 2.0<br />
* which accompanies this distribution, and is available at<br />
* https://www.eclipse.org/legal/epl-2.0/<br />
*<br />
* SPDX-License-Identifier: EPL-2.0<br />
*<br />
* Contributors:<br />
* CEA LIST - Initial API and implementation<br />
* Committer Name (CEA LIST) committer.name@cea.fr - Bug 492522, Bug XXXXXX<br />
*****************************************************************************/<br />
<br />
###############################################################################<br />
# Copyright (c) 2013, 2018 CEA LIST, Committer Name, and others.<br />
#<br />
# All rights reserved. This program and the accompanying materials<br />
# are made available under the terms of the Eclipse Public License 2.0<br />
# which accompanies this distribution, and is available at<br />
# https://www.eclipse.org/legal/epl-2.0/<br />
#<br />
# SPDX-License-Identifier: EPL-2.0<br />
#<br />
# Contributors:<br />
#<br />
###############################################################################<br />
<br />
* '''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.<br />
* '''Strings''': Verify the Non-NLS markers.<br />
* '''Tags''': (@since plugin-number, ...)<br />
/**<br />
* Constructs an Editor for multiple Integer values.<br />
* The widget is a List, with controls to move values up/down, add values and remove values.<br />
*<br />
* @param parent<br />
* The Composite in which this editor is created<br />
* @param directCreation<br />
* Indicates if the creation and modification are directed.<br />
* @param directCreationWithTreeViewer<br />
* Indicates if the creation and modification are directed on the TreeViewer.<br />
* @param style<br />
* The List's style<br />
*<br />
* @since 3.1<br />
*/<br />
public MultipleIntegerEditor(Composite parent, ...){}<br />
<br />
* '''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.<br />
* '''Reexports''': A contributed code should never introduce any 'hidden' dependencies such as reexporting plugins dependencies.<br />
* '''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).<br />
* '''Attributes''': All attributes, field must be at beginning of the class<br />
* '''Returns and conditions''': You can have as many 'return' statement you need in a method.<br />
<br />
* '''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.<br />
<feature <br />
id="org.eclipse.papyrus.XXXXXXX.feature" <br />
version="2.0.0.qualifier"<br />
label="%featureName" <br />
provider-name="%providerName" <br />
license-feature="org.eclipse.license"<br />
license-feature-version="2.0.0"><br />
<br />
<description><br />
%description<br />
</description><br />
<br />
<copyright><br />
%copyright<br />
</copyright><br />
<br />
<license url="%licenseURL"><br />
%license<br />
</license><br />
<br />
<br />
== Merge ==<br />
Eclipse release calendar is detailled [[Simultaneous_Release|here]]. Each date of releases (M1, M2, M3, RC1, RC2 and GA) for the new Eclipse version is defined in a associated wiki page of the Eclipse version). <br />
<br />
Contributions should be merged before:<br />
*M2+<br />
It is forbidden to modify the GUI. Only important bug fixes should be merged. <br />
Creation of a branch (tag) for the release<br />
*M3+<br />
It is forbidden to modify the features and general architecture.<br />
*RC1+<br />
Its forbidden to merge contribution. Only by the project Chief for critical bugs.</div>Patrick.Tessier.cea.frhttps://wiki.eclipse.org/index.php?title=Papyrus/Papyrus_Developer_Guide/How_To-_Code_Contributing&diff=440489Papyrus/Papyrus Developer Guide/How To- Code Contributing2020-09-03T13:56:23Z<p>Patrick.Tessier.cea.fr: /* Code Contribution */</p>
<hr />
<div>__TOC__<br />
<br />
<br />
All papyrus contributors shall follow these rules:<br />
==How to write a Bugzilla task==<br />
When adding a task to the buzilla, the following grammar should be used: <br />
<br />
*'[' ''Category'' ']' ''NameOfTheTask''<br><br />
<br />
The category helps to filter the bugs for developers. There are already some existing categories: General, XXX Diagram, Common, Property View, etc.<br />
<br />
As a reminder, the lifecycle of bugs is located here: [[Development Resources/HOWTO/Bugzilla Use|Bugzilla Use]]<br />
<br />
*Your contribution shall be associated to a bug refenced in the bugzilla.<br />
*When a bug is opened/resolved/closed the Target Milestone must be filled. For example the bug has been fixed for the service release 3 of oxygen, the target milestone is 3.3.<br />
<br />
== Papyrus Plugin Naming Scheme and Folders Structure ==<br />
<br />
*Papyrus plugins naming scheme and folder structure used to locate and name plugins is described here: [[Papyrus/Papyrus_Developer_Guide/Papyrus_Plugin_Naming_Scheme]]<br />
<br />
== CQ ==<br />
* Remember to check on the current CQs to see if they are still current and that we will not miss any currently required dependencies (e.g. glazed lists in the new orbit or the new apache.common.io dependency) as well as the IPlogs. A quick tutorial on CQs can be found [https://wiki.eclipse.org/Papyrus_Developer_Guide/Contribution_Questionaire here].<br />
<br />
== Code Style ==<br />
*'''default''' keyword in Interfaces: should be avoided and only used if unavoidable and justified (to prevent unnecessary API break for example)<br />
*'''var''' keyword is forbidden<br />
*'''lambda expressions''' are allowed, but must be commented to ease the understanding<br />
<br />
<br />
<br />
== How to contribute code with Gerrit (non commiter) ==<br />
<br />
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]]<br />
<br />
== What to do to contribute a patch ==<br />
<br />
(For further information, see http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf) <br />
<br />
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;: <br />
<br />
*(1) I, Forename Name, wrote 100% of the code I've provided. <br />
*(2) This code contains no cryptography <br />
*(3) I have the right to contribute the code to Eclipse. <br />
*(4) I contribute the content under the EPL.<br />
<br />
+ Set the field Review to '?'.<br />
<br />
== What to check before committing a patch ==<br />
<br />
Before commiting a patch, you should verify that the contributor has written the following lines in the comment&nbsp;: <br />
<br />
*(1) I, Forename Name, wrote 100% of the code I've provided. <br />
*(2) This code contains no cryptography <br />
*(3) I have the right to contribute the code to Eclipse. <br />
*(4) I contribute the content under the EPL.<br />
<br />
If not, he must do that before you commit its patch! <br />
<br />
*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;: <br />
**Here is a contribution from one employee of "the name of the company" <br />
**The company has signed a Member Commiter Agreement. <br />
**The contribution does not need a CQ. <br />
**I've committed this contribution. <br />
**Committed revision xxx. <br />
**Set the field iplog to +<br />
<br />
Note&nbsp;: In reality, you should have the autorization of the PMC before doing this commit. <br />
<br />
*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.<br />
<br />
*In all other cases, see http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf<br />
<br />
== Code formatting ==<br />
<br />
*Before to commit, you should verify these items&nbsp;: <br />
**your code is formatted using the Papyrus Template <br />
**each file has an header with the EPL licence and your name <br />
**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.<br />
**the version numbers are correcct. see [https://wiki.eclipse.org/Version_Numbering this guide] for more information.<br />
<br />
*Moreover, if you want to commit a patch, please see the point "How to commit a patch".<br />
<br />
==String Externalization/Internalization==<br />
*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,<br />
<br />
Follow this [[Papyrus_Developer_Guide/Externalize_Strings_In_Java | link]] for a guide on externalization in Eclipse.<br />
<br />
== Write Documentation for Papyrus ==<br />
Each new contribution must contribute to the documentation (behavior changes or new feature). <br />
The documentation must be splitted in two parts: <br />
*user documentation<br />
*developer documentation<br />
<br />
How to - Related to documentation [[Papyrus Developer Guide/Writing Documentation]]<br />
<br />
==Plugin Versioning - Deprecated code==<br />
Using the @Deprecated tag, you must do these things in the same time:<br />
*increase the minor version of the plugin (of course, only if it has not yet be done since the last release)<br />
**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.<br />
* indicate in the comment the plugin version when the class/method became deprecated<br />
* open a bug to remove the deprecated class/method in the next major release<br />
* reference this bug in the comment of the deprecated class/method<br />
* (optional) indicate in the comment in which major release the class/method will be remove<br />
<br />
Add the end, you must have something like that: <br />
<br />
<br />
<nowiki><br />
/**<br />
*<br />
* @deprecated since 3.1<br />
* use {@link org.eclipse.papyrus.infra.gmfdiag.common.structure.DiagramStructure} API instead<br />
*<br />
* This class will be removed in Papyrus 5.0, see Bug 541027<br />
*<br />
*<br />
*/<br />
@Deprecated<br />
public abstract class DiagramStructure {<br />
...<br />
}<br />
</nowiki><br />
<br />
=== Commit message ===<br />
*During the commit&nbsp;: <br />
**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.<br />
<br />
== Code Reviews ==<br />
<br />
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/><br />
Here are some guidelines (which may be altered and/or improved) that every reviewer and committer should follow:<br />
* '''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.<br />
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.<br />
/*****************************************************************************<br />
* Copyright (c) 2015, 2018 CEA LIST, Committer Name, and others.<br />
*<br />
* All rights reserved. This program and the accompanying materials<br />
* are made available under the terms of the Eclipse Public License 2.0<br />
* which accompanies this distribution, and is available at<br />
* https://www.eclipse.org/legal/epl-2.0/<br />
*<br />
* SPDX-License-Identifier: EPL-2.0<br />
*<br />
* Contributors:<br />
* CEA LIST - Initial API and implementation<br />
* Committer Name (CEA LIST) committer.name@cea.fr - Bug 492522, Bug XXXXXX<br />
*****************************************************************************/<br />
<br />
###############################################################################<br />
# Copyright (c) 2013, 2018 CEA LIST, Committer Name, and others.<br />
#<br />
# All rights reserved. This program and the accompanying materials<br />
# are made available under the terms of the Eclipse Public License 2.0<br />
# which accompanies this distribution, and is available at<br />
# https://www.eclipse.org/legal/epl-2.0/<br />
#<br />
# SPDX-License-Identifier: EPL-2.0<br />
#<br />
# Contributors:<br />
#<br />
###############################################################################<br />
<br />
* '''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.<br />
* '''Strings''': Verify the Non-NLS markers.<br />
* '''Tags''': (@since plugin-number, ...)<br />
/**<br />
* Constructs an Editor for multiple Integer values.<br />
* The widget is a List, with controls to move values up/down, add values and remove values.<br />
*<br />
* @param parent<br />
* The Composite in which this editor is created<br />
* @param directCreation<br />
* Indicates if the creation and modification are directed.<br />
* @param directCreationWithTreeViewer<br />
* Indicates if the creation and modification are directed on the TreeViewer.<br />
* @param style<br />
* The List's style<br />
*<br />
* @since 3.1<br />
*/<br />
public MultipleIntegerEditor(Composite parent, ...){}<br />
<br />
* '''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.<br />
* '''Reexports''': A contributed code should never introduce any 'hidden' dependencies such as reexporting plugins dependencies.<br />
* '''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).<br />
* '''Attributes''': All attributes, field must be at beginning of the class<br />
* '''Returns and conditions''': You can have as many 'return' statement you need in a method.<br />
<br />
* '''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.<br />
<feature <br />
id="org.eclipse.papyrus.XXXXXXX.feature" <br />
version="2.0.0.qualifier"<br />
label="%featureName" <br />
provider-name="%providerName" <br />
license-feature="org.eclipse.license"<br />
license-feature-version="2.0.0"><br />
<br />
<description><br />
%description<br />
</description><br />
<br />
<copyright><br />
%copyright<br />
</copyright><br />
<br />
<license url="%licenseURL"><br />
%license<br />
</license><br />
===API===<br />
* Code of plugins shall be inside internal package<br />
* API shall be public and each classe presence shall be justified by implementation of usecase<br />
* The usecase are store inside the plugin the name of the file '''XXX.usecases.md'''<br />
* The grammar is:<br />
### requirement text <br />
* qualified name of the class<br />
<br />
* See the folowing example<br />
<br />
### The profile validation must be done with a button 'Validate Profile plug-in' on plug-in, in the papyrus developer menu<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.handlers.ValidateProfilePluginHandler<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.testers.ValidateProfilePluginTester<br />
* plugin.xml<br />
### During the validation, a progress monitor must be opened with correct explanations<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.handlers.ValidateProfilePluginHandler<br />
### A checker for the extensions must be implemented<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.internal.checkers.ProfileExtensionsChecker<br />
### A checker for the definition profile must be implemented<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.internal.checkers.ProfileDefinitionChecker<br />
<br />
=TO BE CLEANED = <br />
== Plug-ins ==<br />
*All plug-ins must compile and run against JavaSE-1.8. Papyrus 5.0 must compile against openjdk-11.<br />
*Plug-in provider&nbsp;: ''Eclipse Modeling Project'' <br />
*Version&nbsp;: <br />
***Papyrus adheres to the [[Version Numbering|Eclipse Versioning Guidelines]] for API evolution and other kinds of changes''<br />
*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'').<br />
*Plug-in ID&nbsp;: must start with org.eclipse.papyrus <br />
*Plug-in dependencies must not be re-exported.<br />
*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"'')<br />
**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<br />
*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: <br />
**META-INF/ <br />
**about.html <br />
**icons/, images/, resources/, models/, etc. (All folders containing runtime resources) <br />
**plugin.properties <br />
**plugin.xml <br />
**schema/ <br />
*Do '''not''' include the following files: <br />
**.classpath <br />
**.project <br />
**bin/, src/, src-gen/, custom-src/ <br />
**build.properties <br />
*The ''Source build'' (field src.includes in build.properties) category '''must''' contain the '''about.html''' file: <br />
**Optionnally, it may contain the following files: <br />
***.classpath <br />
***build.properties <br />
*It '''must not''' contain the following: <br />
**src/, src-gen/, custom-src/ <br />
**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)<br />
<br />
plugin.xml:<br><br />
[[Image:Papyrus.codestandards.plugin.xml.png]]<br />
<br />
==When to Merge==<br />
Eclipse release calendar is detailled [[Simultaneous_Release|here]]. Each date of releases (M1, M2, M3, RC1, RC2 and GA) for the new Eclipse version is defined in a associated wiki page of the Eclipse version). <br />
<br />
Contributions should be merged before:<br />
*M2+<br />
It is forbidden to modify the GUI. Only important bug fixes should be merged. <br />
Creation of a branch (tag) for the release<br />
*M3+<br />
It is forbidden to modify the features and general architecture.<br />
*RC1+<br />
Its forbidden to merge contribution. Only by the project Chief for critical bugs.</div>Patrick.Tessier.cea.frhttps://wiki.eclipse.org/index.php?title=Papyrus/Papyrus_Developer_Guide/How_To-_Code_Contributing&diff=440488Papyrus/Papyrus Developer Guide/How To- Code Contributing2020-09-03T13:54:42Z<p>Patrick.Tessier.cea.fr: </p>
<hr />
<div>__TOC__<br />
<br />
<br />
All papyrus contributors shall follow these rules:<br />
==How to write a Bugzilla task==<br />
When adding a task to the buzilla, the following grammar should be used: <br />
<br />
*'[' ''Category'' ']' ''NameOfTheTask''<br><br />
<br />
The category helps to filter the bugs for developers. There are already some existing categories: General, XXX Diagram, Common, Property View, etc.<br />
<br />
As a reminder, the lifecycle of bugs is located here: [[Development Resources/HOWTO/Bugzilla Use|Bugzilla Use]]<br />
<br />
*Your contribution shall be associated to a bug refenced in the bugzilla.<br />
*When a bug is opened/resolved/closed the Target Milestone must be filled. For example the bug has been fixed for the service release 3 of oxygen, the target milestone is 3.3.<br />
<br />
== Papyrus Plugin Naming Scheme and Folders Structure ==<br />
<br />
*Papyrus plugins naming scheme and folder structure used to locate and name plugins is described here: [[Papyrus/Papyrus_Developer_Guide/Papyrus_Plugin_Naming_Scheme]]<br />
<br />
== CQ ==<br />
* Remember to check on the current CQs to see if they are still current and that we will not miss any currently required dependencies (e.g. glazed lists in the new orbit or the new apache.common.io dependency) as well as the IPlogs. A quick tutorial on CQs can be found [https://wiki.eclipse.org/Papyrus_Developer_Guide/Contribution_Questionaire here].<br />
<br />
== Code Style ==<br />
*'''default''' keyword in Interfaces: should be avoided and only used if unavoidable and justified (to prevent unnecessary API break for example)<br />
*'''var''' keyword is forbidden<br />
*'''lambda expressions''' are allowed, but must be commented to ease the understanding<br />
<br />
== Code Contribution ==<br />
<br />
=== How to contribute code with Gerrit (non commiter) ===<br />
<br />
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]]<br />
<br />
=== What to do to contribute a patch ===<br />
<br />
(For further information, see http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf) <br />
<br />
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;: <br />
<br />
*(1) I, Forename Name, wrote 100% of the code I've provided. <br />
*(2) This code contains no cryptography <br />
*(3) I have the right to contribute the code to Eclipse. <br />
*(4) I contribute the content under the EPL.<br />
<br />
+ Set the field Review to '?'.<br />
<br />
=== What to check before committing a patch ===<br />
<br />
Before commiting a patch, you should verify that the contributor has written the following lines in the comment&nbsp;: <br />
<br />
*(1) I, Forename Name, wrote 100% of the code I've provided. <br />
*(2) This code contains no cryptography <br />
*(3) I have the right to contribute the code to Eclipse. <br />
*(4) I contribute the content under the EPL.<br />
<br />
If not, he must do that before you commit its patch! <br />
<br />
*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;: <br />
**Here is a contribution from one employee of "the name of the company" <br />
**The company has signed a Member Commiter Agreement. <br />
**The contribution does not need a CQ. <br />
**I've committed this contribution. <br />
**Committed revision xxx. <br />
**Set the field iplog to +<br />
<br />
Note&nbsp;: In reality, you should have the autorization of the PMC before doing this commit. <br />
<br />
*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.<br />
<br />
*In all other cases, see http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf<br />
<br />
=== Code formatting ===<br />
<br />
*Before to commit, you should verify these items&nbsp;: <br />
**your code is formatted using the Papyrus Template <br />
**each file has an header with the EPL licence and your name <br />
**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.<br />
**the version numbers are correcct. see [https://wiki.eclipse.org/Version_Numbering this guide] for more information.<br />
<br />
*Moreover, if you want to commit a patch, please see the point "How to commit a patch".<br />
<br />
===String Externalization/Internalization===<br />
*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,<br />
<br />
Follow this [[Papyrus_Developer_Guide/Externalize_Strings_In_Java | link]] for a guide on externalization in Eclipse.<br />
<br />
=== Write Documentation for Papyrus ===<br />
Each new contribution must contribute to the documentation (behavior changes or new feature). <br />
The documentation must be splitted in two parts: <br />
*user documentation<br />
*developer documentation<br />
<br />
How to - Related to documentation [[Papyrus Developer Guide/Writing Documentation]]<br />
<br />
=== Plugin Versioning - Deprecated code===<br />
Using the @Deprecated tag, you must do these things in the same time:<br />
*increase the minor version of the plugin (of course, only if it has not yet be done since the last release)<br />
**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.<br />
* indicate in the comment the plugin version when the class/method became deprecated<br />
* open a bug to remove the deprecated class/method in the next major release<br />
* reference this bug in the comment of the deprecated class/method<br />
* (optional) indicate in the comment in which major release the class/method will be remove<br />
<br />
Add the end, you must have something like that: <br />
<br />
<br />
<nowiki><br />
/**<br />
*<br />
* @deprecated since 3.1<br />
* use {@link org.eclipse.papyrus.infra.gmfdiag.common.structure.DiagramStructure} API instead<br />
*<br />
* This class will be removed in Papyrus 5.0, see Bug 541027<br />
*<br />
*<br />
*/<br />
@Deprecated<br />
public abstract class DiagramStructure {<br />
...<br />
}<br />
</nowiki><br />
<br />
=== Commit message ===<br />
*During the commit&nbsp;: <br />
**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.<br />
<br />
== Code Reviews ==<br />
<br />
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/><br />
Here are some guidelines (which may be altered and/or improved) that every reviewer and committer should follow:<br />
* '''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.<br />
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.<br />
/*****************************************************************************<br />
* Copyright (c) 2015, 2018 CEA LIST, Committer Name, and others.<br />
*<br />
* All rights reserved. This program and the accompanying materials<br />
* are made available under the terms of the Eclipse Public License 2.0<br />
* which accompanies this distribution, and is available at<br />
* https://www.eclipse.org/legal/epl-2.0/<br />
*<br />
* SPDX-License-Identifier: EPL-2.0<br />
*<br />
* Contributors:<br />
* CEA LIST - Initial API and implementation<br />
* Committer Name (CEA LIST) committer.name@cea.fr - Bug 492522, Bug XXXXXX<br />
*****************************************************************************/<br />
<br />
###############################################################################<br />
# Copyright (c) 2013, 2018 CEA LIST, Committer Name, and others.<br />
#<br />
# All rights reserved. This program and the accompanying materials<br />
# are made available under the terms of the Eclipse Public License 2.0<br />
# which accompanies this distribution, and is available at<br />
# https://www.eclipse.org/legal/epl-2.0/<br />
#<br />
# SPDX-License-Identifier: EPL-2.0<br />
#<br />
# Contributors:<br />
#<br />
###############################################################################<br />
<br />
* '''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.<br />
* '''Strings''': Verify the Non-NLS markers.<br />
* '''Tags''': (@since plugin-number, ...)<br />
/**<br />
* Constructs an Editor for multiple Integer values.<br />
* The widget is a List, with controls to move values up/down, add values and remove values.<br />
*<br />
* @param parent<br />
* The Composite in which this editor is created<br />
* @param directCreation<br />
* Indicates if the creation and modification are directed.<br />
* @param directCreationWithTreeViewer<br />
* Indicates if the creation and modification are directed on the TreeViewer.<br />
* @param style<br />
* The List's style<br />
*<br />
* @since 3.1<br />
*/<br />
public MultipleIntegerEditor(Composite parent, ...){}<br />
<br />
* '''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.<br />
* '''Reexports''': A contributed code should never introduce any 'hidden' dependencies such as reexporting plugins dependencies.<br />
* '''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).<br />
* '''Attributes''': All attributes, field must be at beginning of the class<br />
* '''Returns and conditions''': You can have as many 'return' statement you need in a method.<br />
<br />
* '''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.<br />
<feature <br />
id="org.eclipse.papyrus.XXXXXXX.feature" <br />
version="2.0.0.qualifier"<br />
label="%featureName" <br />
provider-name="%providerName" <br />
license-feature="org.eclipse.license"<br />
license-feature-version="2.0.0"><br />
<br />
<description><br />
%description<br />
</description><br />
<br />
<copyright><br />
%copyright<br />
</copyright><br />
<br />
<license url="%licenseURL"><br />
%license<br />
</license><br />
===API===<br />
* Code of plugins shall be inside internal package<br />
* API shall be public and each classe presence shall be justified by implementation of usecase<br />
* The usecase are store inside the plugin the name of the file '''XXX.usecases.md'''<br />
* The grammar is:<br />
### requirement text <br />
* qualified name of the class<br />
<br />
* See the folowing example<br />
<br />
### The profile validation must be done with a button 'Validate Profile plug-in' on plug-in, in the papyrus developer menu<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.handlers.ValidateProfilePluginHandler<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.testers.ValidateProfilePluginTester<br />
* plugin.xml<br />
### During the validation, a progress monitor must be opened with correct explanations<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.handlers.ValidateProfilePluginHandler<br />
### A checker for the extensions must be implemented<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.internal.checkers.ProfileExtensionsChecker<br />
### A checker for the definition profile must be implemented<br />
* org.eclipse.papyrus.toolsmiths.validation.profile.internal.checkers.ProfileDefinitionChecker<br />
<br />
=TO BE CLEANED = <br />
== Plug-ins ==<br />
*All plug-ins must compile and run against JavaSE-1.8. Papyrus 5.0 must compile against openjdk-11.<br />
*Plug-in provider&nbsp;: ''Eclipse Modeling Project'' <br />
*Version&nbsp;: <br />
***Papyrus adheres to the [[Version Numbering|Eclipse Versioning Guidelines]] for API evolution and other kinds of changes''<br />
*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'').<br />
*Plug-in ID&nbsp;: must start with org.eclipse.papyrus <br />
*Plug-in dependencies must not be re-exported.<br />
*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"'')<br />
**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<br />
*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: <br />
**META-INF/ <br />
**about.html <br />
**icons/, images/, resources/, models/, etc. (All folders containing runtime resources) <br />
**plugin.properties <br />
**plugin.xml <br />
**schema/ <br />
*Do '''not''' include the following files: <br />
**.classpath <br />
**.project <br />
**bin/, src/, src-gen/, custom-src/ <br />
**build.properties <br />
*The ''Source build'' (field src.includes in build.properties) category '''must''' contain the '''about.html''' file: <br />
**Optionnally, it may contain the following files: <br />
***.classpath <br />
***build.properties <br />
*It '''must not''' contain the following: <br />
**src/, src-gen/, custom-src/ <br />
**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)<br />
<br />
plugin.xml:<br><br />
[[Image:Papyrus.codestandards.plugin.xml.png]]<br />
<br />
==When to Merge==<br />
Eclipse release calendar is detailled [[Simultaneous_Release|here]]. Each date of releases (M1, M2, M3, RC1, RC2 and GA) for the new Eclipse version is defined in a associated wiki page of the Eclipse version). <br />
<br />
Contributions should be merged before:<br />
*M2+<br />
It is forbidden to modify the GUI. Only important bug fixes should be merged. <br />
Creation of a branch (tag) for the release<br />
*M3+<br />
It is forbidden to modify the features and general architecture.<br />
*RC1+<br />
Its forbidden to merge contribution. Only by the project Chief for critical bugs.</div>Patrick.Tessier.cea.fr