EMF Client Platform

GETTING INVOLVED

Everyone is invited to get involved with the EMF Client project. Before you plan any kind of contribution, it is a good idea to contact the project team.

Writing bug reports
Please provide a short and concise explanation of the problem and a snippet to reproduce the issue, ideally a JUnit test case that outlines the expected behavior. You are also invited to enter feature requests. Please use Bugzilla to report bugs and feature requests.
Commit Message Guidelines
We have the following commit message template:
```
(Bug <Bug ID> - <Bug Title>) | (TCI - <Fix>)

<Commit Description>?
Change-Id: <Generated Gerrit Change ID>
Signed-off-by: <sign off name and email>
			
```
Instructions (Please continue READING):
- TCI commits: For trivial code changes please use a TCI commit message. See list below for examples. If in doubt please discuss with reviewer.
- Normal Commits: For all other commits use a commit message starting with 'Bug'. Bug reports with Proper Titles: Before using a Bug title for a commit, committer must update the Bug title to a reasonable and descriptive title for the task they have worked on
- Commit Description: Additionally to the title, the commit message can describe briefly (2-3 sentences) how this commit fixes the bug from a technical perspective
- Multiple Commits for same bug: Of course you may use the same bug and therefore bug title for multiple commits and their message, in this case please provide a unique description
- Reviewers responsibility: The reviewer is responsible also for checking that the bug title is descriptive and reflects the committed change and that the description if any reflects the technical change
TCI message examples:
- JavaDoc
- NPE
- Version Update of manifest and pom
- anonymous to inner class Conversion
- Renaming local vars, e.g. because of typos
- Externalizing strings
Use Gerrit to contribute to ECP
We use Gerrit code review so you can easily contribute to ECP and get a review for your changes. Please make sure that all your commits refer to a Bugzilla Bug.
Providing a patch to fix a bug or add a feature
Please attach your patch to the bug report in question or create a new report using Bugzilla .
Contribute documentation
If you found something that is not documented yet, please share your knowledge with other users. Please contact us to find the appropriate place to add your documentation.
Bug report quality policy
Please note that our bug reports (BRs) are an essential source information for adopters to get an overview about applied changes and new features. Therefore, titles must indicate the affected component and express the goal of a change.
It is the reviewer's responsibility to verify that the BR complies with this policy.
Tag bug reports to be retested
If you believe that a change could cause a regression for a consumer please add the "test" keyword to highlight that this feature should be re-tested when a consumer upgrades the affected component. Common instances where this keyword must be added include:
- when the behavior of a component has changed
- when a new feature has been added which is enabled by default
This also includes any changes of the default behavior and adaptations of visible UI elements, even if they are considered an improvement. Further, this includes non-trivial refactorings. If in doubt, prefer to tag a BR.
Additionally to the "test" tag, provide a comment like this:
```
TESTING INFORMATION
Summary of the critical part of the change
Potential regressions
Affected areas / use cases
Things that shall be tested
```
Again, it is part of the code review to check the BR title and the existence of an appropriate comment.
If you identify a regression or change of behavior after the fact, please add the "test" keyword and the testing information as well.
Tag "noteworthy" bug reports
Use this tags on bug reports, that are "noteworthy" especially:
- New features
- Process changes
In general, consider if you would write an article about a release and ask yourself, whether you would mention this bug report. If yes, it is noteworthy. Adopters and developers will use this information to learn what's noteworthy in a release. So please make sure, that "noteworthy" bug reports have a proper description.
Tag bug reports with "Help wanted"
If you want to encourage that other contributors or committers pick up a Bug report, please tag the Br with the "help wanted" keyword. In turn, if you want to contribute to the project, the "help wanted" BRs are a good starting point.

Developer Resources for EMF Forms

Using Oomph we want to ease the setup pain for new contributors and committers of EMFForms. Here are the necessary steps:

Step 1: Download Oomph for your Platform
Step 2: Start Oomph
- Update Oomph to the latest version if required (Simple Mode: Upper right corner or Advance Mode: left bottom)
- Switch to Advanced Mode (Upper Right corner, Advanced Mode)
- Drag and Drop / add ("+" in the upper right corner) this profile EclipseSource Profile
- Select the 'EclipseSource IDE' entry and press next
- Drag and Drop / add ("+" in the upper right corner) this setup file: EMFForms.setup into the top list. You should now see a new Entry at the top:
  
  Select the EMFForms entry and double click it, it should be BOLD now:
- Press next and select the way you want Oomph to install your Eclipse and Workspace
- Press Finish and let Oomph do the magic
Step 3: When Oomph finishes you still have to do some manual steps
- Locate and open the ecp.target file in the org.eclipse.emf.ecp.target.rcp bundle imported from the repository. When it is resolved, set this definition as the target platform. This may take quite some time at first.
Step 4: Start developing using ECP

Framework Developer Documentation

See the developer documentation.

Branching scheme

In our GIT Repositories we are using the branching scheme described here.
We have a master branch containing the last release. A development branch containing the current development state and (hopefully) some feature branches containing new feature developments.
So if you are a developer please commit on the develop branch in the future. If you develop a new feature please open a feature branch and merge it back to the develop branch when your feature is finished. Don't commit on the master branch as it should only contain stable release versions merged there by the release engineer.

Profiling and Performance Debugging