The standard environment to develop Sirius itself is currently:
- Java 1.6. You can use a JRE 1.7 (or later) to run your Eclipse developement environement if you want, but you need a Java 1.6 installed and configured as the default in your Eclipse to make sure the Sirius code works with 1.6.
- Eclipse 4.3.2 (Kepler SR2) SDK, with the following additional plug-ins:
- EMF SDK 2.9.2, available from the Kepler update-site: required to manage our meta-models and generate the corresponding code.
- Eclipse CheckStyle Plug-in 5.6.1, available from http://eclipse-cs.sf.net/update/: required to make sure new code follows the CheckStyle-enforced rules.
- Mylyn WikiText, available from the Kepler update-site: required to re-generated the HTML documentation from the Textile sources.
- EGit 3.3.0: required to get the Sirius sources (not strictly required actually, if you prefer to use the command-line exclusively).
- Maven 3.0 or 3.1, available from http://maven.apache.org/: required to build from the command-line (and make sure your changes will not break the build).
- Optional: Git 1.8 or later, available from http://git-scm.com/downloads, if you need/want to use the command-line for commit/push/merge/rebase/etc.
- Optional: Target Platform Definition DSL and Generator 2.0 or later, available from http://mbarbero.github.io/fr.obeo.releng.targetplatform/p2/latest/ (Note: on Kepler you also need to add http://download.eclipse.org/modeling/tmf/xtext/updates/releases/ to get Xtext 2.5 which is not available by default on Kepler). This tools is needed only if you need to change the Target Platform definition files (
*.tpd) and re-generate the
*.targetfiles. In normal development you do not need this and can simply use the generated
Of course you are free to use any additional tools you want to make your development experience more pleasant for you. However, do not commit anything which adds new requirements without getting approval from the development team.
Getting the Sources
The source code for Sirius is visible at http://git.eclipse.org/c/sirius/org.eclipse.sirius.git. Note that this is a web page, not a Git repository. Do not try to clone using this URL, see instead the URLs at the bottom of that page.
A Team Project Set (
*.psf) file which is normally kept up-to-date can be obtained from http://git.eclipse.org/c/sirius/org.eclipse.sirius.git/plain/releng/org.eclipse.sirius.settings/sirius.psf.
Once you have all the sources in your workspace:
- Make sure the "Missing API Baseline" does not cause compilation errors: Window > Preferences > Plug-in Development > API Baselines : Set "Missing API Baseline" to "Warning" (or "Ignore").
- Open one of the
.targetfiles from the
org.eclipse.sirius.targetsproject in the target editor and (once it is loaded) set it as the current target.
Environment Configuration with Oomph
The steps "Development Environment" and "Getting the Sources" have been replaced by an Oomph configuration file. You need to install the Oomph installer.
- On the Product page, choose "Eclipse Standard" and your desired Product Version (or "Eclipse IDE for Eclipse Commiters" from Mars version).
- On the Projects page,
- add a new project to the catalog from
Sirius.setup(with the green plus button). This file is available in Sirius sources: Sirius.setup,
- then add it to the selection (by double-clicking on it).
- add a new project to the catalog from
- On the Variables page fill all the fiels.
- On the confirmation page just click Finish.
Then, Oomph creates a new Eclipse installation, clones the Sirius git repository (if necessary), launches the new Eclipse install and terminates the process for the current workspace (add the repository in EGit, imports the Sirius projects in corresponding working sets, ...).
If you have trouble by using Oomph installer for Sirius, you can report the problem to the corresponging bugzilla (455965).
Development is done on
master, but all but the most trivial patches must first go through a Gerrit review. Feature branches are created for disruptive changes which may or may not be completely stabilized by the time of the next milestone or release.
Obviously, each contributor is free to do whatever he/she wants on his/her local clone(s), the rules above only apply to commits and branches pushed into the official repo at Eclipse.
Commit Messages Formatting
[bugid] Short description Longer description if needed, explaining the reasons of the change and its impact, not paraphrasing the patch. The description should use wrapped line. Bug: bugid Change-Id: I00000000000000000000 Signed-off-by: author name
- Always mention the numeric bug id at the start of the first line (e.g.
). For the few cases where a commit is not directly related to a bugzilla, use a tag like
- The first line should be short, this is not the place to give details.
Bug: 432432footer line is not strictly required, but Gerrit recognizes it and creates a direct hyperlink to the bugzilla if it is present, which is very convenient.
Change-Id:footer line is mandatory for all changes which go through Gerrit (which should be the vast majority of commits).
Signed-of-by:footer line is not mandatory but recommended.
Cherry-picked-from: 421359footer should be included if the commit is a backport from a cloned issue.
You will need to configure your Sirius Gir repository to be able to push your modifications on Gerrit, see: