Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Graphical Modeling Framework/Development Guidelines

General Information

The bullets below should cover all the tasks one would need to accomplish to become a "plugged-in" member of the GMF development community.

  • Mailing Lists
GMF has two mailing lists, currently. The main developer mailing list [gmf-dev@eclipse.org gmf-dev@eclipse.org] and the release engineering mailing list [gmf-releng@eclipse.org gmf-releng@eclipse.org]. You are welcome to sign up for both, but it is generally sufficient to just be signed up for the developer mailing list. Now, remember that general questions should be posted to the newsgroup and not to the development mailing list! Development topics, architectural discussions, contribution and Committer voting, etc. all take place on the developer mailing list.
To register for the mailing list, you must provide a valid email address and other information here. Note that in order to access the mailing list archive, you need to have a newsgroup user name and password. Information on the newsgroup is below.
  • Newsgroup
As mentioned above, the newsgroup is where general questions are asked and you are encouraged to ask and answer questions as you wish. Look here for information on how to get a password, in addition to a complete list of Eclipse newsgroups.
  • Bugzilla
You will most definitely need a Bugzilla account. Look here for information on setting up an account, using Bugzilla, etc. If you're interested in contributing right away, perhaps you can find something here to work on.

Workspace

You will generally work with three (or more) workspaces. Each is discussed here, along with some overall workspace configuration and tips.

  • Development Instance
In general, you can install whatever you want in your development instance, while most seem to prefer the bare essentials. As long as you have a target instance that is configured properly for GMF development, it doesn't really matter much. You will likely just need to adhere to equal or greater version numbers of both the Eclipse SDK and EMF.
You may elect to configure your development instance to align with the requirements for GMF development and not bother with two... it's up to you. Of course, as we develop against moving targets (Platform, EMF, and GEF milestone releases), using this feature of the PDE is quite useful.
Once your development instance is configured, you'll need to obtain the GMF source code in your workspace. To do this, there are several options, including the CVS Repository Exploring Perspective, a Team Project Set file (one is maintained here), and use the releng tool found here. Each of these is detailed below:
  • CVS Repository Exploring Perspective
In the CVS Repositories view, right click and select New > Repository Location... and fill in according to the dialog shown.
Checkout.png

Note that a Committer will select 'extssh' for the connection type, and use their supplied user name and password. Find your way to /org.eclipse.gmf/plugins and expand it. Although you're able to check out features, examples, tests, etc., for now, just multi select the plug-ins and right-click. Select 'Check out' and sit back. If all goes well, all the plug-ins will be downloaded and built in your workspace.

  • Team Project Set
You can find a gmf.psf file here for use in quickly setting up a workspace with the GMF projects fetched from CVS that you'll need to get started. From File > Import/Export... simply select 'Team Project Set' from the Import list, navigate to the file, and you're done! Another psf file that contains all of GMF is found here.
  • Release Engineering Tool
A nice feature of this little-known tool is its ability to synchronize your workspace to the set of projects found in a map file. Of course, you'll first need to obtain the map file, which for GMF is found in the project org.eclipse.gmf/releng/org.eclipse.gmf.releng which you'll need to obtain from CVS. An alternative is to grab the directory.txt file found on most project download sites, add it to a project in your workspace with a .map extension and right-click to Team > Load Map Projects.
  • Target Instance
The easiest way to find the current requirements for developing GMF is to look at the development update site. The build machine uses a local mirror to install and configure GMF dependencies (and GMF itself, when executing unit tests), so the list here is what is required. Now, try not to use this mirror as your source of obtaining GMF builds and its dependencies.
Now, in order to point your development instance at your target instance that has all the required dependencies for GMF development installed, go to Window > Preferences... > Plug-in Development > Target Platform and point it at the 'eclipse' folder of your target instance.
Gmf target.png
  • Runtime Instance
There are several possible scenarios for working with GMF as a developer. What you focus on will impact how you configure your development workspace and runtime instances. Below is a detailed scenario that represents a possible style of work which will be abbreviated here next. If you get it by reading the abbreviated form, great! If not, hopefully you will after reading the longer version and trying it out yourself.
In brief, you will configure a launch configuration to contain the GMF plug-ins and create a project to work with your diagram/domain/mapping models. Once you're done and have generated your runtime plug-ins, return to your development instance and import those project. Then, create a new runtime launch configuration to test the generated diagram plug-ins, deploying only those and the required runtime plug-ins (no need to have all of the SDK present in this second configuration). Got it?

CVS

Coding

Testing

Bugzilla

Back to the top