Modeling Project Releng

This document is directed to the Eclipse Modeling Framework Technologies (EMFT) [1] component owners and was created help them to set up and run their builds. It describes the existing procedures that all EMFT components are required to adopt, describing, for example, how the files should be organized, what the build files are, and the Integration and Milestone release process.

Note that many of the tips and tricks described herein apply to EMF, MDT, and M2T builds as well.

Throughout this document are references to releng (Release Engineering) files which need to be configured along the way. When a project is first starting, these steps are normally skipped until after all the plugin content is in CVS. Then, and only then, the Modeling Project Releng Module can be created for the new project, and builds can begin.

---

Overwhelmed yet?

Well, you're in luck. As of 2006-07-12, there is a new module template which can be used as a starting point. For more on creating and configuring a Modeling Project Releng Module, see Modeling Project Releng Module. Go there, start with that, then come back here for tips and tricks if necessary.

---

This is a live document! We will be enriching it as questions are raised.

Plugin and Feature Files

The contents of your features and plugins directories should mimic what is available in the EMF and UML2 projects. Although this section tries to summarize the important points, "learning by example" is the recommended approach.

Directory Structure

<example>

We will ask you to organize your files as we've done for EMF and UML2. Basically you will need to create the following directory structure for each subdirectory you own under the EMFT module:

OLD Style -- features intermixed			NEW Style -- features separated
Old EMFT project (/cvsroot/technology) emft/[subproject]/ plugins doc tests examples	- or -	New EMFT project (/cvsroot/modeling/) org.eclipse.*/org.eclipse.*.[subproject]/ plugins doc tests examples	Old EMFT project (/cvsroot/technology) emft/[subproject]/ plugins doc tests examples features	- or -	New EMFT project (/cvsroot/modeling/) org.eclipse.*/org.eclipse.*.[subproject]/ plugins doc tests examples features
plugins: the plugins that provide the function the features that include these plugins + the branding plugins for these features the SDK feature (to generate a bundle that includes source + the plugins) doc: the doc plugins (with the build scripts) the features that include these plugins + the branding plugins for these features tests: the test plugins (with the Eclipse test framework artifacts - such as this one) the features that include these plugins + the branding plugins for these features examples: any plugin you want to use as example the features that include these plugins + the branding plugins for these features			plugins: the plugins that provide the function doc: the doc plugins (with the build scripts) tests: the test plugins (with the Eclipse test framework artifacts - such as this one) examples: any plugin you want to use as example features: the SDK feature (to generate a bundle that includes source + the plugins) all main, source, test, doc, and example features

The directories containing features and fragments must be suffixed by -feature and -fragment respectively.

If you want source plugins and features, you will have to create them.

General Recommendations

• Each feature and plugin directory should be also an Eclipse project, containing all the necessary files such as, for example, .project.
• The .project must only refer to builders available to the open-source community. Also, since Eclipse 3M2, it should not refer to other plugin projects. <example>
• We use CVS to backup the files, so...
  • You can, and probably should, use the $Id$ CVS tag. For more details and other tags read the CVS documentation
  • Add a .cvsignore file to keep unnecessary files (such as the output directory) out of CVS. <example>
• Don't add unnecessary files to your plugins and features. If you use a "non-Eclipse standard" file, please ensure that it has a purpose and that that purpose is clear.
• All plugins should provide the following files:
  • META-INF/MANIFEST.MF <example>
  • plugin.xml <example>
  • plugin.properties <example>
  • build.properties <example>
  • about.html <example>
• The build.properties file is extremely important and must be accurate to allow PDE to build your plugins and features. Please review the EMF build.properties files for plugins with code, documentation and branding plugins, and features.