DEVELOPER GUIDELINES

This page describes the guidelines for creating new plugins and features for EMFForms.

General settings

These settings can be modified in the "New Plug-in Project/New Feature" wizards.

  • Namespace: The plugin-name should begin with "org.eclipse.emfforms". Therefore the name of our example plugin and the prefix for the packages would be "org.eclipse.emfforms.example". The name of a feature would be e.g. "org.eclipse.emfforms.example.feature".
  • Execution Environment: As JRE version the plugin should use 1.6, so please select "J2SE-1.6". (Note that a feature does not have this setting.)
  • Version: As version please use the current version (see in other plugin) plus the qualifier, e.g. "1.0.0.qualifier".
  • Name: Enter a describing name for your plugin, e.g. "Cool Example Plugin".
  • Provider: For the provider please enter "Eclipse Modeling Project".

Plugin runtime

When defining the export packages on the runtime tab, please note the following:
Plugins should export all defined packages. The exported packages should not be visible by default.

  • Internal packages (not visible) should follow the "org.eclipse.emfforms.internal" naming convention
  • SPI packages (visible, breaking changes allowed in minor releases) must follow the "org.eclipse.emfforms.spi" naming convention
  • API packages (visible, no breaking changes allowed in minor releases) should follow the "org.eclipse.emfforms" naming convention

If you don't want to make a potential API package visible yet, please follow the "org.eclipse.emfforms" naming convention but mark the package as not visible.

Plugin dependencies

When adding dependencies to your project please note the following giudelines:
Usually we use "Required Plug-ins" to add dependencies that we need. There is one exceptions: If you add dependencies to SWT/JFace you have to use "Imported Packages".

  • Plugins should have the needed minimum version and the next major version as maximum version, e.g. "[4.8.1, 5.0.0)".
  • Reexport dependencies when you use classes from the other plugins in your API.
  • Imported Packages should have the needed minimum version and the next major version as maximum version, e.g. "[4.8.1, 5.0.0)".

Required legal files

When creating a new plugin make sure to copy the "about.html" from an existing plugin to your project. Then open the build.properties and add the about.html to the Binary as well as to the Source Build.

Formatting & co

  • We set all setting in a project specific way. Therefore no action is required for existing projects. If you want to create a new bundle, please follow these instructions:
  • The lazy and best way is to copy all files from the .settings (except any .api_filters file) folder into the newly created project. You also must copy the .checkstyle file. After that you have to open the project properties and activate checkstyle. The config will already be set to the correct value.

Generating new models

If you have to create a new EMF Model follow these steps before generating:

  • Set the formatting of the project according the formatting rules
  • Set the Code Formatting and the Comment Formatting to true in the genmodel
  • In the genmodel file Set the Copyright Text to:

    Copyright (c) 2011-2015 EclipseSource Muenchen GmbH and others.

    All rights reserved. This program and the accompanying materials
    are made available under the terms of the Eclipse Public License v1.0
    which accompanies this distribution, and is available at
    http://www.eclipse.org/legal/epl-v10.html

    Contributors:
    {userId} - initial API and implementation

Extension Point Guidelines

When adding a new extension point please mind the following guidelines:

  • The plug-in ID must be the same as the ID of the project defining the extension point
  • The point ID must not be fully qualified. The name must be camel cased
  • The point name must be understandable and give a good hint at what the extension point is doing
  • The Description tab must contain a description for the extension point. If the point is experimental (API not fixed) add the following line:
    This extension point is experimental and is likely to change in the future releases as the activity support evolves.
  • The Since tab must contain the Version of the plugin since which it is part of the API. (Even if it is experimental). The Version format is maj.min, e.g. 1.1 .
  • The Examples tab should contain an example of an usage of this extension point. Use the <pre></pre> tags to display markup.
  • The API Information tab should contain a description of classes being used for defining this extension point.
  • The Supplied Implementation tab should contain a description of a supplied implementation of this extension point, if one implementation is supplied.
  • The Copyright tab must contain the copyright agreement, it looks like this:

    Copyright (c) 2011-2015 EclipseSource Muenchen GmbH and others.
    All rights reserved. This program and the accompanying materials
    are made available under the terms of the Eclipse Public License v1.0
    which accompanies this distribution, and is available at
    http://www.eclipse.org/legal/epl-v10.html

    The company name must be adjusted if necessary.
  • You can use HTML tags in all tabs. Use this possibility to improve the readability of your texts.