Fortiss Eclipse Development Tools
The Fortiss Eclipse Development Tools bundle offers a number of
utilities to ease and accelerate the development of Java code, and to
work with EMF metamodels in particular.
It contains the following features that will be explained below in more detail
- Automatic Ecore artifact generation
- Ecore model editor additions
- Warnings Remover
- Code Style Checker
Installation / Updating:
- Fortiss Eclipse Development Tools are installed automatically during the AF3_Developer_Installation.
- The plugins should be updated automatically, by Oomph when Eclipse
is started. Alternatively, you can manually check for updates using
the following update site which is already pre-configured in your
http://download.fortiss.org/public/projects/org.eclipse.systemfocus.tooling.site/MAJOR_VERSION(current major version is 1.1)
- Source code
Automatic Ecore artifact generation
This feature is implemented as an Eclipse Ecore Builder which
automatically generates Java code and other artifacts from
metamodel. The usage scenarios are:
- If project is checked out, the Java code is generated immediately.
- If an ecore model is updated with incoming changes, the generated
Java code and other generated artifacts will be updated
- Model code
Edit code and other artifacts (icons, …) if an
.editplugin has been created for the
- Other Eclipse artifacts (
- If an ecore model contains error, a marker is added the Problem View to trace the error.
Deployment of Ecore Builder
- The Ecore Builder must be declared in the
.projectfile in each model project, according to the following template: @org.eclipse.systemfocus.tooling.emfgeneration.git.EcoreBuilderGIT
- The declaration should be placed in front of the
org.eclipse.jdt.core.javabuilder, so that the generated Java codes can be processed later by it.
ecoremodel must be in the
- The artifacts will be generated in the model code / edit code
directory configured in the
- Note: In order to use Ecore Builder to update
.editplugins, it still only has to be configured in the plugin that contains the corresponding
ecoremodel (i.e., this builder configuration will handle both plugins).
- On project build (autobuild is recommended, see below), the
builder will automatically generate codes and other artifacts from
- The code generator will merge the generated code with existing files that might exist from previous runs.
- Before generating, the
genmodelwill be updated or created.
- After generation, references to foreign
genmodels will be converted to
platform:/resourceURLs instead of a relative path (
../..) as generated by the
ecoremodel editor when saving. This fix is essential because relative paths are known to cause a number of problems (e.g., unexpected modification and copying of metamodels in foreign plugins during build).
- When a clean operation is performed for a project for which Ecore
Builder has been configured, generated artifacts from previous
generation runs will be deleted according to the following policy:
- Model plugins
- Codes that resides in packages that can be traced to the
current version of the
ecoremodel will be deleted automatically.
- For unreferenced code (typically code that resides in
packages that have been deleted in the
ecore), the user is prompted.
- Code that is under revision control is never deleted.
- Codes that resides in packages that can be traced to the current version of the
- Edit plugins
- Also artifacts (code, icons) that are under revision control
are deleted. Rationale:
- Since the generated edit artifacts are often manually modified, the are typically kept under revision control.
- The implemented behavior of (locally) deleting stale
files that are no longer required according the current
version of the
ecoremetamodel supports in synchronizing the edit plugin with the metamodel (the files will be deleted on the Git master repository after a commit).
- Stale entries are removed from the
plugin.propertiesfile as well.
- Also artifacts (code, icons) that are under revision control are deleted. Rationale:
- Protection rules
META-INF/MANIFEST.MFis never modified by Ecore Builder (for model and edit plugins)
plugin.xmlis preserved for model plugins
- The builder can be configured to preserve an arbitrary set of files and folders (see description of builder preferences below).
- Model plugins
Best practices for metamodel modifications
- Do not manually generate code or reload the GenModel (from the
GenModel editor), as this will annul the automatic fixes
provided by Ecore Builder and introduce the following
../..style references in
.ecore files: breaks continous build on https://jenkins.fortiss.org
- (Circular) self-dependency of the plugin containing the
META-INF/MANIFEST.MF): breaks materialization of developer installations via Buckminster
- To trigger code generation, cleaning the respective project is recommended (with Project menu → Build automatically enabled).
Checklist before committing a meta-model modification:
- Trigger refresh of all metamodel related artifacts using clean while autobuild is enabled.
- All modified files must be committed (
- Ensure that none of the typical problems mentioned above
have been introduced (
.ecore, (circular) self-dependency in
- Ensure that generated source code is not added to the
repository (covered by the default
.gitignoreconfiguration that includes the pattern
- When a new sub-package is added to a metamodel, it must be
checked if is correctly registered in the
Addition of a dependency to another foreign metamodel
- Committing any other changes in the workspace is recommended before continuing
- Turn off autobuild
- Ecore Model Editor → Context menu → Load Ressource
- Use add least one type from foreign metamodel
- Save modified
.ecorein text editor and manually replace
.genmodelin text editor, and add the entries to the
usedGenPackagesattribute of the root element of the GenModel (
<genmodel:GenModel) for the following items (pattern:
.genmodelof foreign metamodel
- Transitive closure of the
.genmodels of the dependencies of the new foreign metamodel
.genmodelcorresponding to modified
- Re-enable autobuild
- Clean project containing modified
Double-check the following before committing
- Changes in the
GenModeldependency chain of the modified metamodel (typically caused by forgotten
../..s). In this case, revert the changes to the respective plugins.
- Copies of
.ecorefiles from the dependency chain of the modified metamodel next to the modified
.ecorefile. This is typically caused by incomplete or erroneous extensions of the
- Changes in the
- In case there are still errors: If there are still errors such as non-vanishing error markers on ecore files, you can try to delete the corresponding error markers from the problem view and clean the project again. In case they still appear, the errors are “valid”. Otherwise, they were just “dangling” and blocking the build (resolved by this ste
- Do not manually generate code or reload the GenModel (from the GenModel editor), as this will annul the automatic fixes provided by Ecore Builder and introduce the following problems:
The Fortiss Development Tools → Ecore Builder preference page provides the following options
- The Protected folders/files option allows to configure the
artifacts that should never be modified by Ecore Builder.
- Due to implementation issues, the files may be temporarily modified, but are restored by afterwards to the state before the builder started its clean or build operation.
- Default: no additional protected files or folders (see above
regarding the automatic protection of
Ecore model editor additions
The Fortiss EMF tools context menu adds the following operations to
class, reference, attribute, and operation elements shown in the
Generate comment templates:
- Adds a GenModel → documentation node template to the corresponding model element.
- The documentation provided in the
ecoremetamodel is included into the generated code.
- Hint: Start value of your documentation node with
deprecatedto document elements that should no longer be used.
Generate operation delegate code:
- Generates the GenModel → body node required to link an eOperation with a static Java method using the following pattern:
- Instead of directly providing an implementation of the eOperation, the body node delegates to a static method in a utility class:
- The following conventions are used:
- The name of the utility class is derived by appending the
StaticImplto the Java (interface) class name corresponding to the EClass that contains the eOperation (
- The utility class resides in the same package as the
implementation class (
FooImplin the example) of corresponding to the interface class (
Foo). That way, the generated code can call the utility class without importing the class or the method.
- The name of the method in the same as that of the eOperation.
- The method has the receiver of the method call (
this) as first argument, potentially followed by arguments of the eOperation.
- The name of the utility class is derived by appending the suffix
- To create the utility class, the following approach is useful:
- Create the eOperation body node using the context menu
- Have Ecore Builder generate the code. It will contain errors due to the missing utility class.
- Use the quick fix to generate the class (be sure to have it
generated in to the
srcdirectory where the manually written code is maintained).
- Use the quick fix again to generate the methods
- Change the method signature to use the interface class
Foo) instead of the implementation class (
FooImpl) as type of the first argument.
Code Review Builder
The Code Review Builder updates the icon decoration according to the code review status of the corresponding file resource.
It enabled by declaring the following in the
<buildSpec> of the
.project file in each project:
<buildSpec> <!-- ... --> <buildCommand> <name>org.eclipse.systemfocus.tooling.codereview.builder.CodeReviewBuilder</name> <arguments/> </buildCommand> <!-- ... --> </buildSpec>
Further, the project needs to have the code review nature:
<natures> <!-- ... --> <nature>org.eclipse.systemfocus.tooling.codereview.nature.CodeReviewNature</nature> <!-- ... --> </natures>
The Warnings Remover hides warnings in source folders that (by convention) are known to contain generated code, or code that has been imported from external sources.
Warnings are hidden in source folders that start with one of the following prefixes:
The Warnings Remover is enabled by declaring the following in the
<buildSpec> of the
.project file in each project (after the
org.eclipse.jdt.core.javabuilder, and typically also after
<buildSpec> <!-- ... --> <buildCommand> <name>org.eclipse.systemfocus.tooling.codereview.builder.RemoveWarningsBuilder</name> <arguments/> </buildCommand> <!-- ... --> </buildSpec>
Code Style Checker
The Code Style Checker automates (parts of) the coding guidelines, and creates corresponding warnings (shown the in Problems view and the Java code editor).
The Code Style Checker is enabled by declaring the following in the
<buildSpec> of the
.project file in each project (after the
<buildSpec> <!-- ... --> <buildCommand> <name>org.eclipse.systemfocus.tooling.codereview.builder.GuidelinesCheckBuilder</name> <arguments/> </buildCommand> <!-- ... --> </buildSpec>