I will start with the foundation of every Eclipse 4 application, the application model. In this first part, I would like to introduce the different options for modifying this model.

Application Model vs. Views

In Eclipse 4, the application model defines the workbench, including views, menu contributions and key bindings. The model doesn’t require that you first implement the single components. For example, you can work with the model without implementing a view.

The cornerstones of the application model are windows and parts. Contrary to the eclipse 3.x platform, e4 has combined views and editors into the concept of Parts, which represent views inside a window. If you add a part in the model, you can later connect it to your implementation of the selected view. To show the resulting separation between the general workbench design and the implementation of single parts, I will not show any SWT code in this section. Instead we’ll focus on the model and how to connect the model to code.

The Parts of an application model are connected later to their implementations

Installation

You can get the latest version of Eclipse 4 here:  http://www.eclipse.org/eclipse4/. The IDE itself is based on Eclipse 4 and also contains several useful tools to create RCP and RCP 2 applications. Additionally, we recommend installing the e4 Tools, which, thanks to Tom Schindl, provide a very useful template for creating applications as well as an editor to modify the application model. At writing, these tools are still in incubator status and can be installed from this update site: http://download.eclipse.org/e4/downloads/drops/R-0.12M6-201203151300/repository

The first step

After installing Eclipse 4 the easiest way to get started is to use the e4 template to create a new e4 application. To create a project, choose the „e4 Application Project“ entry within the „new Project“ wizard. For this application you don’t have to change anything except the name of the application. The template creates a product definition and you can start the application simply by starting this product. To start it, open the *.product file and click on run or debug in the upper right corner of the editor. As you can see below, the generated template application already contains a window, two menus, a toolbar and a perspective stack.

Click here to start the product.

The Editor

To modify the application model you’ll need an editor which you can start by opening the Application.e4xmi located in the root level of the project. On the left side you see a tree showing the complete contents of the model. By double-clicking an element in the tree, a detailed view will be opened on the right side allowing you to modify the properties of that element.

The top-level elements of an application are usually one or more windows that you can find in the application model under “windows”. The template project already contains a TrimmedWindow. By double-clicking this element you can, for instance, modify the size of this window. Check the result by restarting the application.

With a right click in the tree, new elements can be added and existing ones can be removed. As an example you can remove the existing PerspectiveStack and just add a single Part instead. After a restart of the application you will notice that the main area of the application does not have a border anymore. However, the new part isn’t visible and it would be nice to have some control over the result. I’ll describe how to do that in the next section.

 Open the application model to modify the workbench

Live Editing

Eclipse allows you to define the workbench using the application model even without providing implementations. However, this is sometimes hard to work with because empty Parts are often hard to identify. To resolve this Tom Schindl introduced the idea of a live editor. It allows you to access the application model of a running application, modify it and highlight selected components. To enable the live editor you need to start two plug-ins along with your application. You can check them in the run configuration and additionally click on “Add required” to include the required dependencies. A run configuration should have been created for you when you first started the product.

In the running application you can start the live editor via ALT+SHIFT+F9. This editor works exactly like the editor in your IDE, however, it directly accesses the application model of the running application. If you, for instance, open the TrimmedWindow in the editor and change its size or position, the changes are directly applied in the running application.

The live editor is not only capable of modifying elements, you can even add new ones. As an example, if you add a new window to the application model (right-click on the tree-node windows), a new window will be opened in the application. To maintain an overview of which components are visible in the application, these components can be colored. By right-clicking an element in the live editor, e.g. the TrimBar and selecting “Show Control”, the control will be colored in red in the running application.

Elements of the application models can be colored in the running application.

Using this feature, one can easily visualize changes within the application model. This is especially useful for elements which are not directly visible in the UI. As an example, if you add a new Part in a Window, it will not be visible without coloring as it does not have any content yet.

If you use the live editor to change the application model the changes will only be reflected in the running application. To transfer them into the deployable application, you can copy the modified version of the model using the tab „XMI“ and copy it into the model available in your IDE.

Programmatical Access to the Model

One of the major advantages of the application model is the ability to modify it via API. As the application model is represented in EMF, the API is very familiar to anyone who has used EMF before. Using this API you can create or modify parts of the application programmatically, for example, reacting to a user action. To test this in the template application you can use one of the existing handlers, such as the class OpenHandler.  As you can see in this handler, there is a method execute() marked with the annotation @execute, which will be executed if the connected ToolItem is pressed by the user.

Dependency injection, which we’ll go into more detail on later, allows the programmer to easily define which parameters are needed within this method. In the following code example the method requires the application window as parameter so it will be injected by the framework. In the first line a new part is created and in the second line this part is added to the window. You can check the result by using the live editor described above. First you’ll need to start the application and the live editor. Then click the open button in the toolbar of the example application. In the live editor you can confirm that the new part has been added correctly and even color it in the application.

@Execute
public void execute(MWindow mWindow) {
    MPart newPart = MBasicFactory.INSTANCE.createPart();
    mWindow.getChildren().add(newPart);
}

In the second code example, a new window is created. To add this new window into the application, the application is required as a parameter. Using the API, the window is sized, a new part is added into the window and the window is added to the application. By adding the window to the application, it is opened in the running application. Restart the application and press the button again to check the result.

@Execute
public void execute(MApplication application) {
    MWindow mWindow = MBasicFactory.INSTANCE.createTrimmedWindow();
    mWindow.setHeight(200);
    mWindow.setWidth(400);
    mWindow.getChildren().add(MBasicFactory.INSTANCE.createPart());
    application.getChildren().add(mWindow);
}

Scripting

Another nice feature of the live editor is the ability to apply scripting and access parts of the model API during runtime. As this code will be dynamically interpreted, JavaScript is used. Scripts can be executed on any part of the application model. To do so, start the application and the live editor (ALT+SHIFT+F9). Right click any element, e.g. a window, and select “Execute script”. In the open window, you can enter JavaScript, which will be wrapped to the Java API. The following code example will set the label of a window – during runtime.

mainObject.setLabel("Hello Eclipse")

This second example will make an element invisible. You can try executing this example on the ToolBar, which you can find in the model tree under TrimmedWindow => TrimBar => WindowTrim => ToolBar

mainObject.setVisible(false)

Conclusion

The e4 application models allows you to define the general design of an application in a consistent way, without implementing single parts in advance. We described different methods to modify the application model, including how to modify the model during runtime using the live editor or the API. At this point we have only created placeholders in the application. The next part of this series describes how to connect the application model with the implementation of UI components, that is, how to create the connection between a part and the implementation of a view filling this part.

For more information, contact us:

Maximilian Koegel and Jonas Helming

EclipseSource Munich leads

Email: e4@eclipsesource.com

This tutorial and all other parts of the series are available as a downloadable PDF.

Author: Jonas Helming

Join me on Google+

This API contains a couple of interfaces that we had trouble to find suitable names for. If you’ve used this API already you know that there were two interfaces side-by-side in the same package with almost the same name: ApplicationConfigurator and ApplicationConfiguration. Even though these names seemed to be correct, it turned out that they were hard to tell apart, and if mixed up in a service declaration, the application did not start, without any warning.

So we reviewed the case and eventually came up with better names for the interfaces without changing the structure. Let me explain the new API and our reasoning behind it.

Implementing an ApplicationConfiguration

A RAP application consists of various parts, such as entrypoints, URL mappings, themes, service handlers, etc. All these parts constitute an ApplicationConfiguration. The configuration is like the blueprint for an application. Based on an ApplicationConfiguration, the framework can create and start an application instance. There can be more than one application instances at runtime, e.g. running on different network ports or different servlet contexts.

Hence, when you write a RAP application, you have to provide an ApplicationConfiguration.

An ApplicationConfiguration is used to configure an application before it is started. For this step, RAP follows a callback approach to leave the responsibility for creating and starting the application with the framework. Therefore, the configuration must actively configure the application. To do so, it has one method configure( Application ). The framework provides a reference to the created Application as a parameter to this method. Here’s how a simple implementation looks like:

public class SimpleConfiguration implements ApplicationConfiguration {
 
  public void configure( Application application ) {
    application.addEntryPoint( "/simple", SimpleEntryPoint.class, null );
    application.addEntryPoint( "/other", AnotherEntryPoint.class, null );
  }
}

Registering the ApplicationConfiguration

When using OSGi, the ApplicationConfiguration can be registered as a service. I’d recommend using OSGi declarative services (DS) like this:

<scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0">
   <implementation class="com.example.SimpleConfiguration"/>
   <service>
      <provide interface="org.eclipse.rwt.application.ApplicationConfiguration"/>
   </service>
</scr:component>

The bundle org.eclipse.rap.rwt.osgi will automatically start this application on every available HttpService. When using Equinox, don’t forget to also include the org.eclipse.equinox.ds bundle. You can find an example of a simple RAP application using DS on github.

When using RWT as a library in a traditional web application, i.e. without OSGi, you can register your ApplicationConfiguration in the web.xml by adding a context-param with the fully qualified class name of the implementation:

<context-param>
  <param-name>org.eclipse.rap.applicationConfiguration</param-name>
  <param-value>com.example.ExampleConfiguration</param-value>
</context-param>

You can always look up the param-name in the constant ApplicationConfiguration#CONFIGURATION_PARAM. The RAP FAQ has a complete example.

Starting an Application

When an ApplicationConfiguration has been registered as described above, the application is automatically started by the framework. Alternatively, it can also be started explicitly using an ApplicationRunner:

ApplicationConfiguration configuration = new SimpleConfiguration();
ApplicationRunner runner = new ApplicationRunner( configuration, servletContext );
runner.start();

There’s a saying that there were only two hard things in computer science, cache invalidation and naming things. I don’t happen to know what’s so tricky about cache invalidation But I can hardly remember any technical problem that caused me as much of a headache as these few names did. I hope that after so many discussions, this new API will prove to be simple to understand and to use.

Thanks to Frank, Rüdiger, Holger and Jordi for great discussions and especially to Frank for contributing this new API to RAP!

The changes are part of RAP 1.5M7, published this Friday, May 11.

Content assist in in package-info files

and enhanced static analysis of case statements:

Checkout the entire new and noteworthy or download the milestone and try it out:

http://download.eclipse.org/eclipse/downloads/drops4/S-4.2M7-201205031800/

]]> http://eclipsesource.com/blogs/2012/05/05/eclipse-juno-milestone-7-available-for-download/feed/ 3 http://eclipsesource.com/blogs/2012/04/23/jnect-kinect-and-eclipse/ http://eclipsesource.com/blogs/2012/04/23/jnect-kinect-and-eclipse/#comments Mon, 23 Apr 2012 10:30:43 +0000 Jonas Helming http://eclipsesource.com/blogs/?p=7547 You might have seen me waving and moving around a lot recently during presentations at Democamps and during my talks at EclipseCon’s. The reason is not a new style in giving talks, but it is the topic: the Jnect project.

The goal of this project is to connect the Microsoft Kinect SDK with Eclipse/Java. In case you do not know the Kinect, it is a device originally built for the Xbox to track human bodies. As persons can be tracked in real-time it allows you to control games, menus and more, just by moving your body. Additionally the Kinect supports speech recognition for pre-defined phrases. Microsoft has also released an SDK for Windows, which allows access to the features of the Kinect in C++/C#. However, there was one important thing missing: Eclipse

Therefore, about a year ago, I and a group of interested students started to work on a way to make the features of Kinect available in Eclipse. Unlike other approaches, we did not want to connect directly to the device and process the raw data. Instead we decided that it would be nice to reuse Microsoft’s SDK which delivers the data processed and on a very high level of abstraction. As an example the SDK delivers the exact positions of different parts of the body of a tracked person.

Building on the SDK, the tricky part was obviously the bridge from C to Java. In a first prototype we used a small C program running in the background and a socket connection to transfer the data from the original SDK to a plugin in Eclipse. This is what I demonstrated last fall at EclipseCon Europe:

In winter another team of students worked on an improvement – the adaptation via JNI. This is more stable and it doesn’t require a second program running, and therefore creates real interoperability.

Not surprisingly we created Jnect as an Eclipse plugin. Recently we created an Eclipse Labs project hosting the plugin (see jnect.org) and we already have a beta-release. It is not perfect yet, but you can test the capabilities of the Kinect and find your use case. Of course, we welcome any feedback and possible contributions. At EclipseCon North America, we were even able to implement a game based on Jnect, which was played during the awards ceremony. The goal was to step thru code as fast as possible using gestures and voice commands. Of course, we have chosen more difficult gestures then just moving a hand. Here you see one of the participants executing the “Step Over” Gesture 

During on our session at EclipseCon, we demonstrated how to move and resize windows in Eclipse 4 using your hands (a little like minority report). This and other code examples are available on jnect.org. You’ll also find videos demonstrating the capabilities of the Kinect as it controls different parts of Eclipse.

Have fun!

When you’re confronted with this problem, you’ve probably either started by designing the server application or are porting an existing server application to be accessible by mobile devices. So, your next step will be to plan how to visualize the server-side app on the clients. The most common approach is to build an App for iOS, Android and so on and render the data in a more or less generic UI. You’ll invest a lot of effort in creating and securing the communication between server and client to get your server-side app ready. And, you’ll have joined the club of developers, including me, who have reinvented the wheel once more.

This is the problem we are solving with RAP mobile. RAP mobile consists of a server and generic clients, with the server based on standard servlet technology and a kick-ass OSGi integration. The server’s open source and hosted within the Eclipse RAP project. The generic clients currently exist for iOS and Android, and in both cases, all the clients do is talk to the server and display a UI. But, every other server-side app does this too. What’s special here?

With usual server-side apps you have to couple the client to the server. The data and message contents are defined and the client needs to understand them, resulting in a more or less a tight coupling between these two all created by yourself. With RAP mobile, the work on communication is done by the framework for you. The server produces JSON based messages that the RAP mobile clients can understand. The messages contain information like “Create a Window, create a Button, set the text of the button to …”, (I think you get it). When you sketch this out it looks like this:

This approach allows us and you (because the server’s open source) to come up with any client as long as it understands JSON. I think the major benefit RAP mobile brings is that you can concentrate on the server-side and your domain requirements, instead of programming a generic UI for every platform.

When you’ve read this far you might now be asking yourself, “When everything is on the server side and I don’t have to write a native UI for the mobile devices, eg. in Objective-C, how does the native UI get created?”  And now the Eclipse open source project comes into the game with Eclipse RAP. RAP provides a widget toolkit which is based on SWT, which means that you write your UI completely in Java. When RAP was created the goal was to enable a developer to create a desktop and a web application with the same code base. As a result, the RAP developers solved problems like multi-user awareness, clustering support, styling and many many more. In the meantime, we’ve gone even further and extended this idea to the mobile space. (And, we’re making good progress, because on the server side we’re working with a mature technology.) In short, it means that when you write a RAP mobile app for iOS, Android and so on, you don’t have to worry about the native client, but you can write your UI in plain Java and run it in the server.

If you’re hungry for more , visit the RAP mobile website, watch the demo videos, clone the examples and run your own app. To join the developer preview, you’ll need to complete a short form but, in a few months we will move into an open beta. I hope you will have fun with this as much as I do. Any feedback is welcome.

I would like to share the links to the presentations, which were shared with me. If you gave a talk and your slides are missing, please send me the link, I will post it here.

Talk 2

Presenter: Mickael Istria

Title: Iterative and agile principles applied to generated code

Slides: http://www.slideshare.net/mickaelistria/iterative-andagilecodegen

Talk 3

Title: What’s new in EGF (Eclipse Generation Factories)

Presenter: Benoit Langlois

Slides: http://wiki.eclipse.org/images/4/47/EclipseCon_US_2012-Whats_new_in_EGF.pdf

Talk 4

Title: You need to extend your models? EMF Facets vs. EMF Profiles

Presenter: Philip Langer & Hugo Bruneliere

Slides: http://www.slideshare.net/HugoBruneliere/you-need-to-extend-your-models-emf-facet-vs-emf-profiles-12163425

Talk 5

Title: EMF Diff/Merge

Presenter: Olivier Constant

Slides: http://wiki.eclipse.org/images/9/98/EclipseCon_US_2012-EDM.pdf

Talk 6

Title: The CDO Model Repository

Presenter: Eike Stepper

Slides: http://www.slideshare.net/Holmes70/cdo-ignite-12281516

Talk 7

Title: EMFStore

Presenter: Maximilian Kögel

Slides: http://www.slideshare.net/koegel/emfstore-demo-eclipsecon2012

Talk 8

Title: EMF Client Platform

Presenter: Jonas Helming

Slides: http://www.slideshare.net/JonasHelming/emf-client-platform-modeling-symposium-eclipsecon-north-america-2012

Talk 9

Presenter: Mickael Istria

Title: What’s up GMF Tooling?

Slides: http://www.slideshare.net/mickaelistria/iterative-andagilecodegen

Talk 10

Presenter: Andres Alvarez & Ruben de Dios

Title: GMF simple map editor

Slides: GMF Simple Mapping Editor (EMS)

Talk 13

Title: MDT/OCL

Presenter: Ed Willink

Slides: http://www.eclipse.org/modeling/mdt/ocl/docs/publications/EclipseConNA2012/EclipseCon2012.pdf

I’ll be giving two presentations on p2 (and likely spending lots of time in the bar talking about p2).  The first presentation is a very gentle introduction to p2.  In this talk we will introduce p2 more pragmatically, presenting the relevant files (profile, content.xml, …), tools (director, mirror, …) and concepts.

In the second talk, It’s Raining Bytes, we’ll discuss how we scale p2 using a variety of cloud technologies.  In particular, we’ll discuss how we deploy over 64,000 plugins (and over store over 500,000 IUs) using different AWS services.

If you’re interested in p2, Yoxos, Eclipse releng, modeling or anything Eclipse related, look for me in the bar or stop by one of my talks.

I look forward to seeing everyone next week!

I originally implemented this as an example of how JavaScript applications can be embedded in RAP as custom widgets. So if you have a similar scenario, you could also use this project as a template. The editor is fairly customizable, read the README for details. You can get the code on GitHub.

After importing the templates you can use them in a test class by typing the first letters of each template and use the content assist (Ctrl/cmd+space) to complete. This results in an assist like the one below. By pressing enter the template will be inserted into your class. Hope this makes test writing easier

The goal of the symposium is to provide an overview of what’s hot and new in the modeling area. We therefore decided to provide many short slots.

Marcelo Paternostro will open the symposium with a 1 minute teaser from his full talk:

“I cheated on EMF with RDF and I may do it again”  (http://www.eclipsecon.org/2012/sessions/i-cheated-emf-rdf-and-i-may-do-it-again).

After that we will have 13 short talks. Each speaker will have 10 minutes including questions. We hope to provide a good overview of what’s cooking in the modeling area. We are looking forward to seeing you there!

Talk 1

Title: Jnario

Presenter: Sebastian Benz

Description: “Jnario” is a framework helping you write executable software specifications. It leverages the expressiveness of Xtend and is easy to integrate, as it compiles to plain JUnit tests. In our other presentation at this EclipseCon, we demonstrate how to use Jnario for writing executable acceptance specifications in a business readable fashion. This session introduces you to Jnario Specs – another language of Jnario allowing software behavior specification on a unit level. We demonstrate how you can design and document your software at the same time.

Talk 2

Presenter: Mickael Istria

Title: Iterative and agile principles applied to generated code

Description: When relying on code generation to produce pieces of your software, you introduce an additional step to your development workflow. This additional step introduce some more complexity, as a drawback of its high productivity. You’ll learn some practical tips to keep you project easy to maintain and benefit of generation at its maximum. Although most examples will rely on GMF Tooling, these principles also apply to other generative frameworks such as EMF and XText.

Basically, it will contain some tips about the generation-gap pattern, why not modifying generated code is a cool things, what are the other ways to customize without modifying. And also I’ll show how to make easier to deal with generation through iterations with GMF Tooling example. I think I can make it in 10 minutes, if we assume most people already used generation frameworks and know there drawbacks.

Talk 3

Title: What’s new in EGF (Eclipse Generation Factories)

Presenter: Benoit Langlois

Description: EGF (Eclipse Generation Factories) is a software factory tool. It is not restricted to text generation but addresses generation in general with issues such as orchestration of heterogeneous activities involved during a generation, generation customization, generation DSL. This talk remind what are the main concepts of EGF (Factory Component, Task, Generation Chain, Portfolio) and the new features that will be available in Juno (e.g., post-processing for model-to-text, support of Ant / JRuby / Acceleo / ATL tasks, enrichment of the EMF generation).

Talk 4

Title: You need to extend your models? EMF Facets vs. EMF Profiles

Presenter: Philip Langer & Hugo Bruneliere

Description: When using the Eclipse Modeling Framework, directly or as part of Eclipse-based solutions, one often faces the problem of having to extend EMF models in an efficient and structured way. However, either due to technical or business reasons, the respective original EMF models/metamodels cannot be modified or “polluted” with the intended additional information.
To this end, an advanced and lightweight model extension mechanism is worth a mint!

EMF Facet<http://www.eclipse.org/modeling/emft/facet/> and EMF Profiles<http://code.google.com/a/eclipselabs.org/p/emf-profiles/>, respectively hosted in Eclipse-EMFT and Eclipse Labs, are two projects implementing such an extension mechanism. The former offers a way to dynamically extend models at runtime, while the latter provides a UML-like profile mechanism adapted to be used for any EMF model.
In this lightning talk, we introduce both tools very briefly and directly demonstrate on a simple example how they can be used in a complementary way.

Talk 5

Title: EMF Diff/Merge

Presenter: Olivier Constant

Description: EMF Diff/Merge is a newly proposed project which aims to provide a lightweight, reliable and scalable engine for comparing and merging models using IDs. It particularly focuses on preserving the integrity and consistency of models during the merge process according to user-defined policies. It includes a customizable diff/merge engine and GUI components which are designed to be used by or integrated into other tools. Envisioned usages of the tool include for example: incremental model transformations, bridges between model-based tools, model refactoring, or merge of models under version control.

Talk 6

Title: The CDO Model Repository

Presenter: Eike Stepper

Description: CDO is a runtime platform for modeled application systems. It provides transparent and highly efficient solutions to most technical challenges with EMF models, such as scalability, transactionality, thread safety, persistence, replication, versioning or collaboration. In this talk you’ll see a brief functional overview and a demo.

Talk 7

Title: EMFStore

Presenter: Maximilian Kögel

Description: EMFStore (http://emfstore.org) is an Eclipse project and a model repository featuring collaborative editing and versioning of models. In this presentation we will demonstrate the recent 0.8.9 release. Further we show how we successfully integrated the EMFStore technology into an existing industrial tool to enable collaborative editing of models and versioning. We will discuss which pitfalls we fell into and which ones we were able to avoid.

Talk 8

Title: EMF Client Platform

Presenter: Jonas Helming

Description: The EMF Client Platform (ECP) provides a generic and reflective user interface for arbitrary EMF models. In this demonstration we present the abilities of the recent 0.8.9 release. But, even though the UI is for free, an important question remains, “Should I use the CDO Model Repository or EMFStore to store my models? Or maybe just XMI files?” We can’t answer this question for you but we’ve done the next best thing. Committers from the EMF Client Platform, CDO and EMFStore have joined forces to enable you to seamlessly switch between the different options. We will give a preview of the upcoming major release onf the EMF Client Platform showing this.

Talk 9

Presenter: Mickael Istria

Title: What’s up GMF Tooling?

Talk 10

Presenter: Andres Alvarez & Ruben de Dios

Title: GMF simple map editor

Description: In order to simplify the creation process of the GMF models we created a graphical tool (Based on GMF) to allow us to create a complete GMF model in a few minutes.

More Info: 

http://modelingsideoflife.wordpress.com/2011/12/13/simple-gmf-model-editor/

Talk 11

Title: EMF Texo

Presenter: Martin Taal

Description: Texo (http://wiki.eclipse.org/Texo) is an EMF code generation and runtime framework targeted for server side web apps. I will demo entity code generation, JPA annotation generation and persistence and some main features of the runtime framework. If there is time I will show how you can adapt or extend the code generation templates making use of the Texo build in support of code formatting, manual-changes-preservation and java import resolving.
A concluding slide will be spend on other not-demoed features of Texo.

Talk 12

Title: Task-focused modeling with Mylyn, EMF and Papyrus

Presenter: Benjamin Muskalla

Description: In order to bring the productivity benefits of the task-focused interface to engineers using Eclipse-based modeling technologies, Mylyn created a “Context Bridge” for EMF-based models and diagram editors. The result of this will be a focused mode for diagrams that shows only the elements related to the task-at-hand, dramatically reducing information overload for engineers working on large models. In addition, the task-focused interface extensions will provide Mylyn’s one-click multitasking facilities for working with models, ensuring that engineers can instantly recover from interruptions, and share model-specific expertise, when working with models in addition to what Mylyn already provides for engineers working with source code. In this session, we will showcase the use of the task-focused interface within the Ecore Tools and the Papyrus UML Editor. In addition, we will discuss the aspects of bringing the task-focused interface to model and diagram editors and will give a quick overview how to enable these for your own diagram types.

Talk 13

Title: MDT/OCL

Presenter: Ed Willink

Description: The major innovation in MDT/OCL for Juno is the addition of Direct OCL 2 Java generation. This enables an Ecore or UML model to be annotated with OCL constraints, so that the previously missing bodies that required manual Java can now be realised directly in a specification language and executed with the aid of the new OCL Transformation Virtual Machine. This eliminates compilation costs at run-time and replaces interpreted execution by inline code exploiting optimized dispatch tables. Combined with the OCLinEcore (Xtext) editor, OCL is finally suitable for modelers as well as Java hackers.