itemis open source lab kiel
itemis Labs Kiel to mentor GSoC projects
We (itemis Labs Kiel) are going to participate in the Google Summer of Code 2008 project.
Google Summer of Code (GSoC) is a program that offers student developers stipends to write code for various open source projects. [GSoC FAQ]
Since our main focus is model driven software development, the projects we will be mentoring will obviously have a modeling aspect as well. We have posted some ideas on the GSoC page on the Eclipse wiki. If you are interested in working with us on a modeling-related project, there are two things you can do:
- Have a look at the list of ideas in the Eclipse wiki. Look for "M2T/Xpand" to see our proposals.
- Write up your own idea and discuss it with us.
Either way, we're looking forward to hearing from you!
Posted at 10:05AM Mar 26, 2008 by Peter Friese in Eclipse | Comments[2783]
EMF - Implementing EOperations without touching generated code
In our current development of M2T/Xpand3 we make a lot of use of Ecore models. Although, there are a lot of obvious advantages in using the Ecore implementation over implementing domain models using Java directly, there are some problems.
One of them is that EMF's generator encourages you to use generated code. As we don't want to do that for several reasons, we had to find another way.
EMF's generator supports specification of Java code via a specific EAnnotation. But of course we don't want to program Java within small properties text widgets. Instead we developed an Action, which automatically adds the respective EAnnotaions with delegation code to each EOperation.
So here's an example. First there is the plain ecore file:
The Action we built can be invoked via context menu and transforms it to something like the following:
EMF's generator now generates the nested delegation code instead of the the usual "throw new UnsupportedOperationException();"-code.
Of course there are compile errors at first....
but after adding the referenced class and needed methods manually the compiler is happy again:
The delegation implementation for abstract types even supports some kind of polymorphism:
So we can add special implementations for more specfic types when needed (i.e. subclasses):
Posted at 12:30PM Mar 11, 2008 by Sven Efftinge in Eclipse | Comments[883]
Convergence of Editors
I've created a screencast showing our latest progress in simultaneous model editing with
- an Xtext editor,
- a GMF editor
- and a generic editor (new).
Posted at 11:59AM Feb 28, 2008 by Jan Köhnlein in Eclipse | Comments[428]
Enabling UUIDs in EMF Resources
EMF allows linking models across resource borders. To identify the referenced element, the standard XMIResourceImpl uses XPath expressions. If a model element is contained in an EReference with a multiplicity greater than one, its ID ends in its index number in that list.
In many cases, this can cause serious trouble, if model elements are reordered without all referencing resources being loaded in the same resource set. IDs change without the referencing plug-in taking notice, and references are scrambled or broken in the end. This happens for example, when you reorder the elements of a GMF graph model in the GMF graph model editor after creating the GMF map model. You will usually end up fixing all references manually...
We have implemented an EMF Resource that uses UUIDs instead of the XPath expressions. In fact, this feature is already there in the XMIResourceImpl, but it has to be enabled. To use our implementation, you have to register its resouece factory with the file extension of your models.
Our tests show, that EMFs standard XMIResource handles even mixtures of explicit UUIDs and XPath IDs gracefully, i.e. a model with UUIDs can nevertheless be referenced with XPath expressions. It can also still be loaded in an XMIResource. Nevertheless, we recommend to use either UUIDs or XPath IDs for a given extension. In the case of migration to UUIDs, you should convert all models at once.
Posted at 04:13PM Feb 26, 2008 by Jan Köhnlein in General | Comments[723]
EValidator adapter for oAW check
There are couple of advantages to write model validation in the oAW Check language rather than in OCL. One of the few disadvantages was, that Check had not yet been fully integrated into EMF's validation framework. For example, in order to add Check validation to your GMF model editor, you had to use oAW's GMF adapter, which is quite a complex task involving extension models and aspectual template changes.
We have now implemented an oAW Check / EValidator adapter and a check registry to bridge that gap between EMF and oAW.
EMF usually performs checks using a class called Diagnostician, that delegates to the EValidators registered for the respective EPackage.
Diagnostic diagnostic = Diagnostician.INSTANCE.validate(modelElement); -> ... EValidator validator = EValidator.Registry.INSTANCE.getEValidator(modelElement.eClass().getEPackage()); validator.validate(modelElement.eClass(), modelElement, diagnostics, context);Our new adapter wraps oAW Check validation into EMF's EValidator interface.
OawEValidatorAdapter validator = new OawEValidatorAdapter(myEPackage);
validator.addCheckFile("mychecks.chk");
Usually, you won't have to deal with the adapter, as we designed an extension point that allows you to register Check files to EPackages that instantiates and registers the adapter automatically. <extension point="de.itemis.emf.oaw.check.checks">
<metaModel nsURI="http://www.itemis.de/emf.oaw.check.test">
<checkFile path="de/itemis/emf/oaw/check/model/check1.chk"/>
<checkFile path="de/itemis/emf/oaw/check/model/check2.chk"/>
</metaModel>
</extension>
Existing registered validators are aggregated by default.
In the GMF example, it's now easy to add validation with oAW Check
- Change gmfgen model to enable EMF validation.
- Set "Validation Decorators", "Live Validation UI Feedback" and "Validation Enabled" of the Gen Diagram to true.
- regenerate your editor
- Write your oAW Check files in a seprate plug-in.
- Register check files to the extension point.
Posted at 05:36PM Feb 22, 2008 by Jan Köhnlein in Eclipse | Comments[844]
Workspace-aware EPackage registry
We have implemented a new EPackage registry for Eclipse modeling tools.
The existing EPackage.Registry.INSTANCE only keeps entries to installed EPackages, i.e. EPackages in Eclipse plug-ins that are registered to the org.eclipse.emf.ecore.generated_package extension point. It is implemented as a map that stores (nsURI, EPackage) or (nsURI, EpackageDescriptor) pairs. When you write a modeling tool, you want to access Ecore models in the workspace in a similar way.
In the workspace scenario, nsURIs are no longer unique identifiers, as you could e.g. have two different versions of the same Ecore model in different projects. As for the classpath URI, we use the project to additionally qualify the nsURIs.
// existing EMF registry
EPackage.Registry.INSTANCE.getEPackage("some_nsURI");
// workspace aware registry
EPackage.Registry.INSTANCE.getDescriptorForJavaProject
(myJavaProject, "some_nsURI");
As EPackages in the workspace are subject to continuous changes, we don't keep references to the EPackages themselves, but use EPackageDescriptors. Descriptors are kept when the EPackage changes and they are only discarded if an EPackage is deleted. So a modeling tool can always access the same descriptor to get the most recent version of the EPackage.
EpackageRegistryDescriptor descriptor =
EpackageRegistry.INSTANCE.getDecriptorForJavaProject
(myJavaProject, “http://de.itemis/mymetamodel.ecore”);
EPackage ePackage = descriptor.getEPackage();
To benefit from the new EPackage registry, the user must install an Eclipse builder on all projects containing Ecore resources. The builder listens to changes of model files and keeps registry up to date.
For further convenience, the registry adds a classpath URI for each registered model in the global URI map.
ResourceSet rs = new ResourceSetImpl();
Resource resource = rs.getResource
(URI.createURI("classpath:/my.java.project/model-folder/mymetamodel.ecore"), true);
Posted at 04:51PM Feb 22, 2008 by Jan Köhnlein in Eclipse | Comments[510]
Classpath URI protocol
We have just finished the implementation of the classpath URI protocol.
From within an Eclipse execution environment, EMF model files are usually referenced using platform:/plugin or platform:/resource URIs. In a standalone Java environment, you will have to use file URIs. Due to that mismatch, modeling tools developed for Eclipse are sometimes hard to reuse in other environments.
The classpath URI protocol allows uniform access to EMF resource files in the classpath of
- installed Eclipse plug-ins,
- Java projects in the workspace and
- standalone Java applications.
classpath:/[<project>/]<path>/<file>Project is the name of the Eclipse plug-in or project, that can be installed in the workbench or located in the workspace. It qualifies the path and file name to the classloader the respective Eclipse plug-in/project. If the global classpath is targeted, the project is omitted.
The path is always relative to the classpath, so jar-files are transparent. That leads to much shorter URI's that follow classloader conventions.
The classpath URI protocol is implemented in the ClasspathUriConverter class, a custom URIConverter that has to be registered to the ResourceSet in use.
Eclipse examples:
ResourceSet rs = new ResourceSetImpl(); rs.setURIConverter(new ClasspathUriConverter()); rs.getResource(URI.createURI(“classpath:/myproject/some/java/pkg/myfile.ecore”); // load a resource from Java package some.java.pkg rs.getResource(URI.createURI(“classpath:/myproject/some/pkginjar/myfile.ecore”); // load a resource from the Java package some.pkginjar inside some jar on the classpath of myproject rs.getResource(URI.createURI(“classpath:/org.eclipse.emf.ecore/model/Ecore.ecore”); // load a resource from the installed plug-in org.eclipse.emf.ecoreNon-Eclipse example:
ResourceSet rs = new ResourceSetImpl(); rs.setURIConverter(new ClasspathUriConverter()); rs.getResource(URI.createURI(“classpath:/some/java/pkg/myfile.ecore”); // load a resource from Java package some.java.pkg womewhere on the classpathTo avoid ambiguities, the ClasspathUriConverter can only resolve URIs to existing files. It uses the global URIConverter.uriMap to store the classpath URI/resolved URI pairs.
The classpath URI protocol will also be employed in our new EPackage registry.
Posted at 04:00PM Feb 22, 2008 by Jan Köhnlein in Eclipse | Comments[8412]
Roadmap
Just wanted to post something about the stuff we're working on the next months. After adding some really cool features to the current version of Xtext together with Bernd (we haven't talked about all of them yet ;-)), fixing bugs in oAW 4.2 and getting the TMF project up, we have to migrate the Xpand/Xtend language-tandem to work with Arno's new backend.
The backend supports compilation as well as interpretation. In addition everything is well encapsulated just like a VM. So what we need to do is "just" model the AbstractSyntaxTree using EMF, develop the needed parser, a transformation to te backend's model, add some features needed by GMF and finally create some nice tooling. We're still not sure whether to rely on IMP here or not,...
Meanwhile we are developing a workspace based EPackage registry. The registry provided by EMF just works for installed EPackages, but we need to reference EPackages defined somewhere in the workspace (as in previous oAW versions). The registry needs to be scoped so that one can only see models which are in the current or referenced projects. Furthermore we are working on a 'classpath:' scheme for EMF's URIs. As this as well needs some context (e.g. the IJavaProject) it will not be transparently be integrated into EMF's API but instead has to be explcitely resolved. Anyway it will be public API and included within M2T because it's needed there.
In addition we have developed an extension point used to register check files for EPackages. Such check files are wrapped in a special EValidator implementation which itself is registered in EMF's validation registry. So this will be the new way for all kinds of editors (TMF, GMF, generic, etc) to get models validated using check.
In addition we'ld like to have an implementation for ItemProviderFactory where you could specify labeling and icons for your meta models using Xtend. Unfortunetely, neither EMF's generated editors nor GMF's editors use the respective registry provided by EMF so far (Why is this?).
So what we ultimately are going to do is to provide some possibilities to register an ecore model together with it's checks and label/icon providers implemented using Xtend. Later on we could add support for declarative description of different views (outline, navigator, type hierarchy) as well as common ways of how to find references or declarations of model elements and how to open and select them using their default editor.
With such facilities in place the definintion of an editor is much easier, and common stuff can be shared between editors.
We're also working on a new MWE editor providing code completion and static type checking as well as a wizard framework making the definition of all kinds of wizards much easier. It will be based on dynamic EMF (and databindings) for describing the wizard pages and Xpand/Xtend for describing what to generate.
Last but surely not least Xtext will go to TMF. As mentioned in an earlier post Xtext now implements EMF's Resource API. This somewhat revolutionizes working with eclipse modeling tools as we will show sometime next week when Jan (GMF-Expert) has finished a hopefully cool screencast. Of course TMF/Xtext will have some additional features maybe be based on IMP and be stable with explicitely defined public API.
We'll keep you updated!
Posted at 09:35PM Feb 21, 2008 by Sven Efftinge in Eclipse | Comments[7810]
Generic Modelling
We've developed a new generic EMF editor, which is based on Forms and EMF Databindings. It also uses Check and Xtend in order to change representation and validation of dynamic models. Most of the work has been done by my colleague Dennis.
We're not sure where exactly we're going to release it, but it will be open-source and be included in openArchitectureWare 5.
Here is a short demonstration.
Posted at 01:51PM Feb 21, 2008 by Sven Efftinge in Eclipse | Comments[273]
Xtext : support for references
We've added support for inter-file references in Xtext.
Leveraging EMF's URI mechanism one can now declare a built-in token "URI" like so:
Model : (imports+=Import)*
(entities+=Entity)*;
Import : "import" fileRef=URI;
...
A model could look like:
import "platform:/resource/my.project/models/mymodel.dsl"
...
As a result there will be an extension fileRef(Import this), which returns the resource's "eContents" (list of model elements) of the referenced EMF resource.
The allElements() extension used throughout Xtext now includes all referenced model elements as well, so that linking, validation or code completion automatically use the referenced models. If you need sophisticated import semantics one can of course overwrite these default semantics.
Because referenced models are loaded using EMF's ResourceFactory facilities, Xtext now generates an implementation to Resource and ResourceFactory for each language and registers them using the provided extension points (at runtime it uses the API).
As a side effect it is now possible to reference Xtext-based models from other EMF models.
Posted at 11:53AM Feb 18, 2008 by Sven Efftinge in Eclipse | Comments[529]
Welcome to our blog
This is the blog of itemis labs in Kiel.
We're a small team of software engineers (part of itemis AG) working on open-source projects such as the Eclipse Modeling Project and openArchitectureWare.
In order to provide transparency to everybody interested we'll post about our ideas, newly developed enhancements and tools in this blog.
Stay tuned.
Posted at 11:37AM Feb 18, 2008 by Sven Efftinge in General | Comments[2185]
