|
|
|
This project serves as an umbrella for small tools and models that make the development of EMF-based software more productive. The following packages are currently available:
Unless otherwise noted, all software provided here is made available under the terms and conditions of the Eclipse Public License v1.0.
Rate this plugin @ Eclipse Plugin Central
This tool provides support for simple structural comparison of arbitrary EMF models using the Eclipse Compare framework (the emphasis is on simple as there is a proposed EMF Compare project that is much more sophisticated.) This is especially useful when developing Ecore models in a team setting where multiple developers can make changes to the model. The traditional method -- comparing the model's text source -- makes it often too difficult to recognize relevant structural changes.
Model comparison is a difficult subject, especially in the general case. This tool uses the given Resource's proper containment hierarchy to create a tree representation of its structure. Each contained object in turn exposes its non-transient features as leaves. Attribute features are compared on the basis of their values; reference features (even containment proxies) are compared by their URIs. Same-document references use only their fragments, cross-document references fully resolved URIs. The result of this comparison is then displayed in a multi-column tree with the compared features in the first column and their corresponding values in subsequent columns (two or three, if the comparison is three-way). If possible, changes can be copied from one side to another using the context menu or tool buttons in the editor's top-right corner.
Content-level comparison is left up to whichever content compare viewer is registered for the given content type. By default, it is a simple text viewer used for generic text comparison (if the underlying resource input stream is indeed textual in nature). For XML resources, this tool makes the best effort to link each node to its corresponding text range, to the extent that the underlying XML parser supports it. However, some nodes may not be accurately linked to their XML source (such as features mapped to XML attributes, for instance) because standard XML parsers do not provide such precise location information. As a result, care must be taken when clicking through structural differences as they may not automatically hightlight corresponding textual differences. One must also be careful when merging textual differences as making inappropriate changes may invalidate the model.
The structural difference viewer for EMF models is initially bound to Ecore, Genmodel and XMI files, but users can use it with other types of EMF models by binding the desired file extension to the "Generic XML Document" content type in their Preferences.
The following packages are available for download:
The latest release can also be obtained through our Update Site at http://www.eclipticalsoftware.com/updates. It has been built with Eclipse 3.2.2, EMF 2.2.2, and JRE 1.4.2.
This feature contributes several extensions that aim to improve developer experience when working with EMF GenModels and generated code.
1. A Java search participant searches GenModels (the *.genmodel files) in the requested scope and reports any references to the searched Java types or packages. Typically, the EMF code generator produces a number of classes for each element in the GenModel. For instance, there are classes that are generated for the model (e.g., edit and editor plug-in classes), for each package in it (e.g., AdapterFactory, Switch, ItemProviderAdapterFactory, etc.), as well as each class (e.g., interface, implementation class, item provider, test cases, etc). This feature allows you to find GenModel(s) responsible for generating the given package, class, or interface.
2. Several menu actions are added to the GenModel Editor's context menu to allow the user instant access to generated artifacts (GenModel editor is the default editor used to edit *.genmodel files). For instance, right-clicking a GenClass node allows you to open the corresponding generated interface and implementation classes, as well as the item provider and test case, if any. Similar actions are available at the package level (GenPackage). At the model level (GenModel), it is possible to open the foreign model used as the source of the GenModel, if it is a local file.
3. A Java element decorator highlights EMF-generated types, methods, and fields in structured viewers, such as the Content Outline or Package Explorer. That is, all code marked as@generated in its Javadoc comment is displayed in different
color (blue is the default). Code that is explicitly marked as @generated NOT
is also highlighted using a different color (red is the default). Both colors
are user-configurable using the Preferences dialog (under Java -> Appearance
-> EMF-generated Code Decorator).
The goal of this feature is to provide the developer with instant feedback as to which parts of the code being viewed are EMF-generated and which parts have been explicitly customized. This is particularly useful when navigating large models (with potentially many customizations) in team environment.
4. Similarly, Java structure viewers (such as Java Editor's Content Outline or Package Explorer)
can be customized with three additional filters that hide methods and fields
whose Javadoc comments contain @generated or @generated NOT
tags, or don't have either one.
5. Java Editor's context menu sports a "Customize EMF-Generated Method" action. This action simply creates a "*Gen" copy of the selected methods and marks the originals as "@generated NOT". Initially, these methods delegate to their respective "*Gen" versions but may be further customized as necessary.
The following packages are available for download:
The latest release can also be obtained through our Update Site at http://www.eclipticalsoftware.com/updates. It has been built with Eclipse 3.2.2, EMF 2.2.3, and JRE 1.4.2.
Standard EMF-generated editors, including those for editing Ecore and GenModel files, lack the ability to search for simple text strings. This otherwise ubiquitous function is quite useful, especially when working with large files. Without it, for instance, finding a particular type or feature in a large Ecore file requires one to carefully scan its entire contents. This plugin adds simple Find/Replace functionality to existing EMF-generated editors in a non-intrusive way.
In the latest release, the solution was reimplemented to use the standard text editor Find/Replace dialog. It is enabled for all EMF-generated editors that do not already provide their own Find/Replace action implementation.
The following packages are available for download:
This release can also be obtained through our Update Site at http://www.eclipticalsoftware.com/updates. It has been built with Eclipse 3.2.2, EMF 2.2.2, and JRE 1.4.2.
This feature allows you to browse the content of Ecore (*.ecore) and GenModel (*.genmodel) files in the new Project Navigator. This view is not shown by default in either the Java or the PDE perspective; you can find it in the Show View dialog under General -> Project Navigator.
The latest release of this feature fixes potential memory leaks and issues with resource change tracking. It also adds support for displaying the selected object's attributes in the Properties view.
Note that the Ecore/GenModel file content displayed in the navigator is not editable -- you must first open it in the appropriate editor.
The following packages are available for download:
This release can also be obtained through our Update Site at http://www.eclipticalsoftware.com/updates. It has been built with Eclipse 3.2.2, EMF 2.2.2, and JRE 1.4.2.
By default, EMF-generated editors are set up to work with a specific file extension typically derived from the Ecore package name (e.g., *.ecore for the Ecore package itself). However, using a common extension, such as *.xml, is often more desirable. The problem arises when multiple editors are bound to the same extension -- which EMF model is stored in the file?
The Eclipse platform already supports the notion of content types -- a custom "describer" class can be used to identify a file based on its actual content. For EMF model files, this entails "peeking" at the first XML element in the document and determining what Ecore model it belongs to. Model-specific editors can then be bound to the defined content type rather than a particular file extension.
<extension
point="org.eclipse.core.contenttype.contentTypes">
<content-type
base-type="org.eclipse.core.runtime.xml"
file-extensions="xml"
id="feed"
name="Atom Feed Document"
priority="normal">
<describer
class="ca.ecliptical.emf.contenttype.describers.XMLRootElementNSContentDescriber"
plugin="ca.ecliptical.emf.contenttype.describers">
<parameter
name="namespace"
value="http://www.w3.org/2005/Atom">
</parameter>
<parameter
name="element"
value="feed">
</parameter>
</describer>
</content-type>
</extension>
...
<extension point="org.eclipse.ui.editors">
<editor
id="ca.ecliptical.emf.atom.presentation.AtomEditorID"
name="%_UI_AtomEditor_label"
icon="icons/full/obj16/AtomModelFile.gif"
class="ca.ecliptical.emf.atom.presentation.AtomEditor"
contributorClass="ca.ecliptical.emf.atom.presentation.AtomActionBarContributor">
<contentTypeBinding
contentTypeId="ca.ecliptical.emf.atom.feed">
</contentTypeBinding>
</editor>
</extension>
Even though the platform provides a describer for XML content, it is unfortunately
not powerful enough in its current form -- it doesn't support recognition of namespaces
(only root element names and DTDs). In EMF, namespaces are important. This feature
provides an alternative describer (XMLRootElementNSContentDescriber)
that supports the use of namespaces for recognizing content.
In addition to binding editors to content types, you might also need to load EMF models elsewhere regardless of their URI extension. Because EMF only provides extension-based Resource Factory registrations, this feature provides an extension point that supports binding of custom Resource Factories for specific content types. That is, you can register a custom Resource Factory implementation for a defined content type rather than a URI extension. This information is then used by a customized Resource Factory Registry and may be applied to any ResourceSet instance.
<extension
point="ca.ecliptical.emf.contenttype.contentParsers">
<parser
class="ca.ecliptical.emf.atom.util.AtomResourceFactoryImpl"
contentTypeId="ca.ecliptical.emf.atom.feed">
</parser>
</extension>
You can make your Resource Set use the Content Type-aware Resource Factory registry
by calling ContentTypeResourceFactoryRegistry.create(resourceSet).
This creates a new registry and installs it into your Resource Set. Any URIs
resolved within this Resource Set will use the registered content type/resource factory
bindings to discover the appropriate resource factory.
The following packages are available for download:
The latest release can also be obtained through our Update Site at http://www.eclipticalsoftware.com/updates. It has been built with Eclipse 3.2.2, EMF 2.2.2, and JRE 1.4.2.
This feature consists of a simple model and a customized XMLResourceImpl extension
that together provide support for representing XML Processing Instructions (e.g.,
<?xml-stylesheet href="http://www.atomenabled.org/css/atom.css" type="text/css"?>
in EMF models. XML Processing Instructions are not supported in EMF up until version 2.3
(yet to be released).
To add support for Processing Instructions to your model, modify your model's Resource implementation to subclass PIResourceImpl instead of XMLResourceImpl. Furthermore, add PIItemProviderAdapterFactory to your ComposedAdapterFactory instances. When a Processing Instruction is encountered in the context of a mixed-content element (or the document root), it will be added to the corresponding feature map, much like text, comments, and CDATA sections.
The latest release fixes the "Invalid entry feature" exception encountered with EMF 2.2.2.
The following packages are available for download:
The latest release can also be obtained through our Update Site at http://www.eclipticalsoftware.com/updates. It has been built with Eclipse 3.2.2, EMF 2.2.2, and JRE 1.4.2.