A Focus on Hibernate Changes

by kaers at October 12, 2015 11:45 AM

Over the past two years we have been working hard to rationalize and improve the support for different Hibernate versions in the JBoss Tools suite. This effort has resulted in real multiversion support but some of the changes may have an impact on the way how you tackle your Hibernate projects in JBoss Tools. Read on if you are a user of Hibernate reverse engineering tooling and of the Hibernate console configuration.

Why Did We Need These Changes in the First Place?

Already for a long time there was support for multiple Hibernate versions in JBoss Tools. When creating a console configuration for instance, it was possible to select the desired version using a dropdown box.


After choosing the appropriate version for a console configuration, and using this console configuration for the reverse engineering of entity classes from the database, one can see below that effectively the selected version of Hibernate was used for the generation (in this case 4.0).


OK, so far so good. But when we needed to provide support for JPA 2.1 we stumbled across a major problem. We added the Hibernate 4.3 runtime which contains JPA 2.1 support and all seemed to be going well. Unfortunately we found that expanding the created console configuration for JPA 2.1 projects resulted in the error message below.


Investigation of this problem showed that there was a mixup of Hibernate classes due to a mistake in the dependency graph between the different Eclipse plugins that contained the respective Hibernate runtime contributions. At this point the dependencies looked like the schema below.


It turned out that, no matter what Hibernate version you chose for the console configuration, expanding the configuration in the Eclipse view was always using the Hibernate 3.5 classes exposed by the org.hibernate.eclipse.libs plugin. To summarize, some of the functionality of the Hibernate tooling in Eclipse was using the chosen version properly while the rest of the functionality was always using version 3.5.

OK This Looks Messy Indeed, How Did We Solve It?

So the problem with the schema above is the direct dependency of the org.hibernate.eclipse plugin (as well as some other of the Hibernate tools Eclipse plugins) on org.hibernate.eclipse.libs. This last plugin contains the Hibernate 3.5 runtime as well as some other related libraries and it effectively hides the Hibernate runtime classes that are contributed by the different org.jboss.tools.hibernateX_Y plugins.

The correct solution for this problem was, as is fairly classical in software engineering, to introduce an additional layer of indirection.


As you can see above a new org.jboss.tools.hibernate.runtime.spi plugin was created. In the Hibernate tools Eclipse plugins only classes and interfaces from this SPI plugin are used while all the immediate uses on core Hibernate classes were removed. A number of runtime provider plugins then implement these SPI interfaces and contribute their functionality by means of the Eclipse extension point mechanism. Also the org.hibernate.eclipse.libs plugin was removed.

As an additional step and to eliminate a lot of duplicated code in the different runtime plugins, we moved to a situation in which a lot of the code was moved to an abstract implementation of the Hibernate runtime providers. All the concrete uses of the actual Hibernate classes remained in the Hibernate runtime provider classes.


How Does All of This Affect Me, Avid Hibernate Tools User?

The most important change that can possibly effect you is the removal of the org.hibernate.eclipse.libs plugin. Not only did this plugin contain the classes of the core Hibernate 3.5 runtime but it also included some Hibernate related classes that are considered optional. Among these where cache implementations such as Ehcache and connection pool implementations such as C3P0. As caching and connection pooling are not really relevant for the tooling and as there are way too many possible options for them to be all included in all of the Hibernate runtime providers, we decided to not include them anymore.

So if you include classes from these optional bundles in your Hibernate configuration file, you will probably bump against problems like this issue.

Assume like in this case that you want to use second level cache and use the Ehcache implementation. So you have written a Hibernate configuration file in which you have defined the session factory like as follows:

              <property name="hibernate.connection.driver_class">org.h2.Driver</property>
              <property name="hibernate.connection.url">jdbc:h2:test</property>
              <property name="hibernate.dialect">org.hibernate.dialect.H2Dialect</property>
              <property name="hibernate.cache.use_second_level_cache">true</property>
              <property name="hibernate.cache.use_query_cache">true</property>
              <property name="hibernate.cache.region.factory_class">
              <mapping class="..."/>

When you create a Hibernate console configuration in Eclipse using this definition, and you will try to expand it, this will result in an error like shown below. Evidently, because the org.hibernate.eclipse.libs plugin containing the org.hibernate.cache.ehcache.SingletonEhCacheRegionFactory class was removed, a ClassNotFoundException will be the cause of this SessionFactory error.


This problem can be solved in two possible ways. The first way is to add the jar files containing the missing classes to the project class path. As can be seen on the image below, the console configuration can now be expanded without an error.


One can argue that it is not a very clean solution to pollute the project class path with artifacts that are not really needed just to make the tooling run properly. This is a valid point and it is the reason why we have a second solution that is probably preferable.

In this case you can just edit the console configuration by using &aposEdit Configuration&apos from the context menu. In the opened dialog, you can switch to the Classpath page and add the missing jar files. The image below illustrates this approach.



Because of the architectural changes that we implemented for the Eclipse Hibernate tooling, real support for multiple versions of Hibernate is now available and working properly.

The removal of the org.hibernate.eclipse.libs plugin introduced the possibility of missing some classes when working with the Hibernate console configuration in Eclipse. As we showed, this can be easily fixed by directly adding the libraries containing the missing classes on the class path of the console configuration.

Thanks for reading!
Koen Aers

by kaers at October 12, 2015 11:45 AM

EMF Forms 1.7.0 Feature: Runtime View Model Migration

by Maximilian Koegel and Jonas Helming at October 12, 2015 11:33 AM

With Mars.1, we released EMF Forms 1.7.0. EMF Forms makes it really simple to create forms that edit your data, based on an EMF model. To get started with EMF Forms please refer to our tutorial.

In this post, we want to outline a new feature of the 1.7.0 release: Runtime migration of view models.

Short Story

In case we change the view model definition, we provide migration support to enable you to keep your existing view models up to date. This should be done in your development time, when switching to a new release. In 1.7.0, we added a fall-back enabling the migration also during runtime. Please see our migration guide for more details. However, runtime migration should be a fall back, we recommend to pro-actively migrate your view models.

Longer Story

The main concept of EMF Forms is a declarative language to describe form-based UIs, the View Model. It is simpler and more focused than programming UIs with a UI toolkit such as Swing, SWT, or even with HTML. See here to learn more about the advantages of this approach. When using EMF Forms, the View Model becomes the central artifact to define a form-based UI, it therefore contains a lot of value. As a consequence, the View Model is expected to be a long living artifact. The View Model is even independent of UI technologies, it is translated by a UI Toolkit specific rendering component. Therefore, the View Model can even be re-used when migrating to a new UI technology, e.g. when migrating from a desktop to a browser application.

While the technology independent format provides advantages, we need to take special care of the View Model to enable its long-term maintenance. The technical basis is well-chosen for this requirement. The view model is defined in

However, even if EMF went away, your view models are not lost. Due to its declarative nature, it is easy to transform the view model in any other format, which has a comparable expressiveness. As an example, we have recently added an exporter to transform view models into a JSON format (see jsonforms.org). This enables view models to be used in pure web contexts and completely independant of EMF.

Another potential threat for the view model artifacts would be incompatibilities with new versions. This would mean an old View Model is not compatible with a new version renderer, provided by EMF Forms, by JSON Forms or custom renderer. To avoid this problem, in the past, we have dones two things. First, we design the view model in a very modular way making it easy to add new concepts without affecting the existing ones. This worked well, since in version 1.4.0, we managed to keep the number of relevant changes on the View Model down to three (see here). However, we also do not want to keep things in the View Model, which are not optimal. So some changes are unavoidable. For these cases, we provide migration support. This mechanism, supported by Edapt, will automatically migrate your view models to a new version and therefore ensure compatibility (see here for more technical details). Migration is an explicit step, so, you need to trigger it when updating to a new version of EMF Forms (in case there are relevant changes).

In the past, if you did not migrate your view models, you may have received an error when starting an application. For this case, we added another safety net: Runtime View Model Migration. There is a new component, you can add to your runtime application. For every view model loaded, it checks the compatibility, and if necessary, migrates it on the fly. Please see our migration guide for more details. However, please note that Migrating View Model during runtime is not recommended as a regular practice. The runtime migration needs to take place on every application startup. This feature is intended to serve as a fallback only, if a legacy View Model was not migrated at development time and made its way to production code. So please migrate your view models proactively.


Leave a Comment. Tagged with eclipse, emf, emfforms, eclipse, emf, emfforms

by Maximilian Koegel and Jonas Helming at October 12, 2015 11:33 AM

ECF Remote Services: Distribution Providers

by Scott Lewis (noreply@blogger.com) at October 11, 2015 01:09 AM

ECF's modular implementation of OSGi Remote Services supports the runtime selection of a distribution provider.  Distribution providers are responsible for the underlying communication when a remote method call is made.

ECF commiters and contributors have been adding distribution providers, and we are now up to 9 publicly available providers:  ECF generic, r-OSGi, websocket r-OSGi, JMS/ActiveMQ, MQTT/Paho, Jax-RS Jersey, Jax-RS CXF, Hazelcast, and REST-API-based providers,

We've documented these distribution providers, so that consumers may compare and contrast them, understand dependencies, and have working examples in case they choose to create their own distribution provider.

by Scott Lewis (noreply@blogger.com) at October 11, 2015 01:09 AM

Respect, it’s all we all ask for

by Doug Schaefer at October 10, 2015 03:27 AM

Am I an asshole? Yeah, sometimes. I have strong opinions and I have a habit of saying the wrong thing and getting people mad at me. But it’s usually in cases where I see people treated unfairly and I try to stand up for them, usually very poorly.

We have a great group of contributors to Eclipse who work their asses off to make it better, often on their own time and their own dime. Often they have good ideas and I hate to see those ideas not given a fair shake. Everyone has an opinion and that’s what makes a community vibrant. But every idea and every contributor should be given respect. If you don’t you equally lose respect.

I made this comment on the UTF-8 default encoding bug that I hope resonates with people. Knowing how things go, I’m sure I’ll piss off just as many people.

Remember when you make decisions like this, you are making them on behalf of the
community, the entire community, not just your employer and certainly not only
yourself, and that you are doing it with respect for the opinion of those who've
commented on this bug and elsewhere. Then hopefully the respect would be mutual.
There are millions of users out there. Our products are successful because Eclipse
in the large is successful. We need to make sure we protect that.

My point is that when you make a decision when working on an open source project you have to take into consideration the entire community that’s impacted by that decision. With Eclipse, especially the Java side, it’s gigantic. And for us vendors, its a few orders of magnitude larger than the number of our customers. So when you make a decision that’s not in the best interest of the masses, it will sooner or later come back to bite you. You don’t want to go into a customer engagement and have the prospect say, “you built on Eclipse? Eclipse sucks!” That’s not good business.

It’s hard for us committers and leaders to see that. It’s miles apart from that moment of decision to where something like that could happen. But I try and keep it in mind when making design decisions I make. And if it causes a little short term pain for my customers, well that’s my problem to solve, not the community’s. If someone has a good idea, it’s my duty to treat it with respect and in the end it could make the product better for everyone, including my customers.

by Doug Schaefer at October 10, 2015 03:27 AM

Eclipse Neon and Saneclipse adding full screen mode for Eclipse

by Lars Vogel at October 09, 2015 10:25 AM

In the Eclipse Neon build from yesterday you have the option to trigger a “Full Screen mode”. We added it simultaneously to saneclipse. saneclipse is a set of plug-ins to improve the user experience of the Eclipse IDE and can be installed into Eclipse Mars.

You can use the “Toggle Visibility of all Toolbars” command (via Quick Access) to hide all currently visible toolbars. Selecting the command again, reveals these toolbars again. This allows the developer to maximize the space available for editors and views. If you minimize a stack after you selected this command, the minimized stack will be visible, until you trigger the command to hide the toolbars again. This allows the developer to decide which minimized stacks are useful for him.

The following is a screenshot of the IDE with a maximized Java editor and several toolbars visible.


The next screenshot shows the same maximized editor but with hidden toolbar.


The shortcut to trigger this is Ctrl+Alt+M on Windows or Linux and Command+Alt+M on Mac.

Please note that we do not hide the main menu, we think that would be to confusing for the user, which accidently trigger this. And this command will soon be available via the Windows menu.

Combined with the upcoming shortcuts for increasing and decreasing the font size of the current editor this should make Eclipse also easier to use for people using Eclipse for presentations.

by Lars Vogel at October 09, 2015 10:25 AM

Hello Andrea!

by Mike Milinkovich at October 08, 2015 01:30 PM

A few weeks ago, Andrew called me into his office, and told me “I’m sure you’ve figured this out already, but I’m transgender.” To which I replied “Uhhh….I had no idea. ” I am so oddly oblivious to these sorts of things, it’s sad.

Today Andrew becomes Andrea.

Wh‎at I know already is that Andrea retains all of the attributes that made me want to work with Andrew. She is a warm, and funny person who cares deeply about the technologies, communities, and people she works with. She is committed to her family and local community. We are lucky to have her at the Eclipse Foundation, and as part of the Eclipse, Eclipse Science,  and LocationTech communities. She is on a very courageous journey of personal discovery, and to a small degree, we’re along for the ride.

‎Andrea is at once both an old and a new member of the Eclipse community. Please give her a warm welcome.

Filed under: Foundation

by Mike Milinkovich at October 08, 2015 01:30 PM

CDO 4.4.1 Is Available: New User Interface and Documentation

by Eike Stepper (noreply@blogger.com) at October 08, 2015 10:26 AM

The new CDO Explorer with its new user interface was already released with Mars in June 2015 and I've already blogged about it: Collaborative Modeling with Papyrus and CDO (Reloaded)

Now with CDO 4.4.1 the documentation has been augmented with a beautiful User's Guide and an extensive Operator's Guide.

Please browse the release notes to see what else has changed.

Again, special thanks go to CEA for generously funding the following:
  • Branching and interactive merging
  • Support for offline checkouts
  • Interactive conflict resolution
  • Documentation
Download CDO 4.4.1 and enjoy the best CDO ever!

by Eike Stepper (noreply@blogger.com) at October 08, 2015 10:26 AM

vogella GmbH joins the Eclipse Foundation

by Lars Vogel at October 08, 2015 08:47 AM

On behave of the http://www.vogella.com/company/ I’m happy to announce that we joined the Eclipse Foundation. While our employees were already heavily involved with the Eclipse open source framework since several years, this step makes our company commitment official.

We work on almost all Eclipse Platform projects and we are happy to currently be the second strongest contributor to the Eclipse Platform.


We are also leading the Eclipse Platform UI project and it is great to see more and more new people coming in and help with the project. Still we remain very active in this project and it is great for us to see that we are currently doing more than 50 % of the commits in Platform UI.


Many of our customers are using the plug-in development tools, we are also heavily involved in them.


But of course that is not all, we believe that it is important to also help other projects to improve the Eclipse IDE experience, so we contribute to various projects. Our Eclipse vogella GmbH company page lists the projects we are involved in, here is a current snapshot.


We definitely love the Eclipse Platform and are very impressed with the skills in the Platform team, we are looking forward to work closer together with the Eclipse Foundation. We also hope to continue and intensify our efforts in improving the Eclipse IDE and Platform experience and are looking for qualified developers located in Germany, fulltime or part time (students).

by Lars Vogel at October 08, 2015 08:47 AM

Vert.x 3.1.0 is released !

by purplefox at October 08, 2015 12:00 AM

I’m pleased to announce the release of Vert.x 3.1!

Some of the highlights of this release include:

  • Vertx-sync is a set of utilities that allow you to perform asynchronous operations and receive events in a synchronous way, but without blocking kernel threads.

  • Vertx-stomp is an implementation of a STOMP server and client. You can use the STOMP server with other clients and use the STOMP client with other servers. The server and the client supports the version 1.0, 1.1 and 1.2 of the STOMP protocol. The STOMP server can also be used as a bridge with the vert.x event bus.

  • Vertx-shell is a command line interface for the Vert.x runtime available from regular terminals using different protocols.

  • Re-implementation of the Starter class and related functionality. And now redeploy is back!

Full release notes can be found here:


Breaking changes here:


NPM for the event-bus client here:


Many thanks to all the committers and community whose contributions made this possible.

A special thanks to the full-time team - Clement, Julien and Paulo who put in a lot of work to get this out :)

Next stop is Vert.x 3.2 which we hope to have out before Christmas.

The artifacts have been deployed to Maven Central and you can get the distribution on Bintray.

by purplefox at October 08, 2015 12:00 AM

Launch Bar 2.0 for Neon

by Doug Schaefer at October 07, 2015 08:57 PM

Screen Shot 2014-03-14 at 10.08.11 AM

I’ve been working on the Launch Bar for it seems like forever. But it’s still only used by a few people in the Eclipse world and I haven’t really made a push to get others to adopt it. I don’t think it’s quite ready for that. I’ve really been struggling with it’s place in Eclipse. It fills a missing need as far as improving the Launch experience.

It’s also filling a missing API need, the ability to specify where you want to Launch to. And I’m now thinking that this needs to be directly added to Platform Debug so that the launch target is passed on to the launch configuration delegate so it can pass it on to the launch, build for launch, etc. And if we’re going to do that, we should really put the launch bar down into the Platform Debug as well.

And if we’re doing that we should really not be using IRemoteConnection as the launch target as the Launch Bar does now. I’ve received a number of requests to generalize the target concept since not everyone gets why they need to use the new remote system. It’s funny as I actually had started with a more general concept anyway. So I’m going back to that.

But it does mean there will be API changes so the Launch Bar for Neon will be a major release, 2.0. The end goal is to contribute it to Platform Debug but I won’t have time for that in Neon. But we will get the APIs in shape so it’ll be ready for Neon + 1.

In the meantime, I have a release of the Arduino C++ IDE to put out which does use the Launch Bar. I’ll be producing a video of how to use it and I think from that you’ll see the value the Launch Bar really adds, especially when you have multiple targets where you want to launch your application.

by Doug Schaefer at October 07, 2015 08:57 PM

JBoss Tools and Red Hat Developer Studio for Eclipse Mars

by akazakov at October 07, 2015 04:19 PM

JBoss Tools 4.3 and Red Hat JBoss Developer Studio 9 for Eclipse Mars are now generally available!

Java 8 is required for installing and using JBoss Tools. We still support developing and running applications using older Java runtimes. See more in Beta1 blog.


JBoss Developer Studio comes with everything pre-bundled in its installer. Simply download it from our JBoss Products page and run it like this:

java -jar jboss-devstudio-<installername>.jar

JBoss Tools or Bring-Your-Own-Eclipse (BYOE) JBoss Developer Studio require a bit more:

This release requires at least Eclipse 4.5 (Mars) but we recommend using the latest Eclipse 4.5.1 Mars JEE Bundle since then you get most of the dependencies preinstalled.

Once you have installed Eclipse, you can either find us on the Eclipse Marketplace under "JBoss Tools" or "Red Hat JBoss Developer Studio".

For JBoss Tools, you can also use our update site directly.


What is new ?

There are many new features and improvements. The full list of what is new you can find on this page. Hundreds of bugs have been fixed on JBoss Tools side but we also continue to work on making Eclipse better and contribute to many Eclipse projects: Web Tools, Docker, Maven Integration, JavaScript, Hybrid Mobile Tools and many others.

Let me highlight just a few major features in JBoss Tools 4.3 and JBoss Developer Studio 9.

OpenShift 3

There is a new tooling available to help you with OpenShift 3 application development.

new connection wizard

OpenShift 3 tooling is provided as a TechPreview feature, available from the JBoss Central Software/Updates page. We are working on improving OpenShift 3 tooling and it will be included in JBoss Developer Studio by default as a Supported feature in the upcoming months.


Tooling for Docker is available in Eclipse Mars under the Linux tools umbrella. Despite this name, this works on all major developer platforms. It is mirrored on JBoss Tools update site and is also included in Developer Studio 9.

docker explorer view


Java EE 7 Batch Tools include an advanced Job XML editor, wizards, validation, navigation, and other features.


Where is integration stack tooling?

The integration stack covers the tooling for Fuse, Drools, jBPM, SwitchYard, JBoss ESB etc.

They are available as "Early access" in JBoss Tools under JBoss Central Software/Update page.

In the near future it is planned to also show up in JBoss Developer Studio and eventually be available as fully supported.

What is Next

Having JBoss Tools 4.3 and JBoss Developer Studio 9 out we are already working on the next maintenance release for Eclipse Mars. We are also working on Eclipse Neon adoption.


Alexey Kazakov

by akazakov at October 07, 2015 04:19 PM

Updates in the Docker Tooling

by xcoulon at October 07, 2015 08:42 AM

As Eclipse Mars.1 is landed a few weeks ago, let’s take a look at the main new features that we`ve worked on since our first release in June.

Improved Docker Explorer View

We’ve added icon decorators on the containers to show their state. This makes it clearer if a container is running, paused or stopped.

Improved Docker Explorer View

New Dialog to Search and Pull Images

We’ve worked on the workflow to pull and search images from Docker Hub. The updated &aposPull Image&apos wizard can be launched from the &aposDocker Images&apos view or from the &aposDocker Explorer&apos view (a new context menu entry is available on the connection node and on the &aposImages&apos node)

Pull Image Wizard

The wizard detects the tag in the image name and if none is specified, the image tagged latest will be pulled.

If the user needs to search a specific image name, she can click on the &aposSearch…​&apos button which will open the &aposSearch&apos wizard:

Search Image Wizard

followed by a second page that displays all the tags for the selected image:

Search Image Tags Wizard

Even though this wizard can only search from Docker Hub, users can nonetheless pull images from other third-party registries. In that case, image name needs to be prefixed with the registry host and port, such as

New Launcher to Build a Docker Image

Finally, we`ve also added a new launcher to build images from a Dockerfile.

Build Image Launcher

The source path is a directory in the workspace or on the file system and the &aposDocker Connection&apos combo box specifies on which Docker daemon the image will be built.

As always, feedback, feature requests and bug reports are welcome. Since this tooling is developped at Eclipse.org, you can join us on our public mailing-list or use Bugzilla to report any bug or feature request.

Have fun !
Xavier Coulon

by xcoulon at October 07, 2015 08:42 AM

Saneclipse now with keybindings to increase / decrease editor font size

by Lars Vogel at October 07, 2015 06:49 AM

Based on the work of Mickael Istria we added shortcuts for increasing and decreasing the editor font size to Saneclipse.

Install the latest version from https://dl.bintray.com/vogellacompany/saneclipse/ and enjoy Ctrl++ or Ctrl+- for changing the font size.

We hope to integrate Mickaels change into Neon.

by Lars Vogel at October 07, 2015 06:49 AM

Creating Custom Slack Commands with JAX-RS

by aaronlonin at October 06, 2015 07:46 PM

Many teams, including ours, now use Slack for team coll […]

The post Creating Custom Slack Commands with JAX-RS appeared first on Genuitec.

by aaronlonin at October 06, 2015 07:46 PM

LiClipse 2.4.0 (Critical fix for TextMate bundles and PyDev update)

by Fabio Zadrozny (noreply@blogger.com) at October 06, 2015 11:17 AM

The latest LiClipse (2.4.0) is now available to download.

The major fix was in the integration with TextMate bundles, which was applying some indent rules when the user didn't really add a new line.

Also, this version adds support for RAML (http://raml.org/).

Besides that, the bundled PyDev was upgraded to the latest version, which had some nice improvements such as improved ansi colors in the interactive console, more information when all elements were filtered out in the PyDev Package Explorer, code completion improvements, etc.

See http://liclipse.com for more information on LiClipse and http://pydev.org for PyDev.

by Fabio Zadrozny (noreply@blogger.com) at October 06, 2015 11:17 AM

EclipseSource Oomph Profile: Updated to Mars.1

by Maximilian Koegel and Jonas Helming at October 06, 2015 08:07 AM

Mars.1 was successfully released on Friday, October 2nd. “Mars.1” is the first “service release” for Mars. The community has decided not to call the second and third release of one release stream “service” releases, as many participating projects also add new features. However, specifically the core components mainly focus on stability in Mars.1 and Mars.2 and therefore, we recommend to always update the IDE to the newest version. We updated the EclipseSource Oomph Profile accordingly, so, if you use our profile, you just need to restart your Eclipse IDE, and all updates will be applied for you. If you are running multiple instances, please close all except the one you restart. The update will take a while and run in the background, you can observe the status in the progress view on the bottom of your IDE. Once the update is finished, you need to restart again, the update should be completed and you should see the new splash screen. Please see here to learn how to use the EclipseSource Oomph profile.


Leave a Comment. Tagged with eclipse, EclipseSource Oomph Profile, oomph, eclipse, EclipseSource Oomph Profile, oomph

by Maximilian Koegel and Jonas Helming at October 06, 2015 08:07 AM

EclipseCon North America 2016 - Call for Papers

October 05, 2015 03:49 PM

The call for papers is now open. Be the first to submit your talk!

October 05, 2015 03:49 PM

EMF Forms and EMF Client Platform 1.7.0 released!

by Maximilian Koegel and Jonas Helming at October 05, 2015 12:29 PM

We are happy to announce that together with Mars.1, we have released  EMF Forms and EMF Client Platform 1.7.0! We want to thank all committers and contributors for their work as well as the active ecosystem of users and adopters for the feedback and support!

EMF Forms is a framework focused on the creation of form-based UIs. EMF Client Platform is designed to support the development of applications based on an EMF data model. If you are not yet familiar with EMF Forms, please refer to this tutorial for a introduction.

Both frameworks are part of Eclipse Modeling Tools Mars.1 (new name for SR1), but you can also find the new release on our download pages:

Please have a look at our migration guide, if you are upgrading to the new version.

We are proud of our team with 15 active contributors.



In the last release cycle, due to holiday season, we had a slightly decreasing number of commits. However, since June 2015 and with the 1.7.0 release, we have again closed an impressive number of 91 Feature Requests and Bug Reports.
We will describe the most notable new features in this blog over the next weeks. We hope you enjoy the new release and provide us with feedback!


Leave a Comment. Tagged with eclipse, emf, emfcp, emfforms, eclipse, emf, emfcp, emfforms

by Maximilian Koegel and Jonas Helming at October 05, 2015 12:29 PM

Tycho 13: Generating API documentation

by Christian Pontesegger (noreply@blogger.com) at October 05, 2015 09:47 AM

If you want to add API documentation to your feature you want to make sure that documentation and implementation are consistent. Running javadoc manually is not ideal, better integrate documentation generation in your tycho build.

Tycho Tutorials

For a list of all tycho related tutorials see Tycho Tutorials Overview

Source code for this tutorial is available on github as a single zip archive, as a Team Project Set or you can browse the files online.

Step 1: Create a help plug-in

We need a hosting plug-in for our API documentation. So create a new Plug-in Project named com.codeandme.tycho.help and mavenize it with Packaging set to eclipse-plugin. Add it to your master pom as usual.

Eclipse help is provided by adding extension points for org.eclipse.help.toc elements and according xml files. I will not go into details here as Lars did an excellent job with his tutorial on eclipse help.

For our project we provide 2 'classic' toc entries along with xml files: main.xml and reference.xml.

The third entry in plugin.xml (referring to help/api_docs.xml) does not have a corresponding xml file as we will create this one on the fly with maven.

We intend to generate documentation to a folder help/api-docs/javadoc. As tycho will not create this folder automatically, we need to add it manually.

Step 2: Configuring tycho

Documentation creation is a step we want to do for the help plug-in only. Therefore the following changes will go to com.codeandme.tycho.help/pom.xml and not to our master pom.

<mainLabel>Tycho Tutorial API</mainLabel>
<!-- enable in case you need a proxy for web access
The property tycho.extras.version was added in our previous tutorial. Please add it to the master pom, if you did not do this already.

Lets look at some of the pom options:

Line 20 defines the TOC xml file to be created. Its display name is defined in line 22. TOC generation might be disabled by setting <skipTocGen>false</skipTocGen>
Lines 35-38 will add links to external documentation for standard java classes.
Lines 39-43 will add links to the eclipse API documentation typically shipped with every release.

Step 3: Define plug-ins for documentation creation

Typically you do not want to create documentation for all plug-ins. Test plug-ins for example should not show up there. Therefore we need to maintain a list of all plug-ins that should be considered by tycho.

This list is stored in com.codeandme.tycho.help/build.properties. Add them as extra classpath entries:
jars.extra.classpath = platform:/plugin/com.codeandme.tycho.plugin
To provide multiple plug-ins, add a comma-separated list (like for the bin.includes entry).

Tycho will create documentation for exported packages only. With the current project configuration com.codeandme.tycho.plugin does not export anything. You have to export a package there or tycho will fail to build.

Finally make sure to add the help folder to your binary build in build.properties.

Congratulations, you API documentation is now up to date for every build.

by Christian Pontesegger (noreply@blogger.com) at October 05, 2015 09:47 AM

Launching with EASE

by Jonah Graham at October 04, 2015 03:01 PM

Launching with EASE - using auto completionLaunching with EASE – using auto completion

I have been doing some experiments with Eclipse EASE in preparation for determining the suitability – and creating a prototype – of using EASE with non-JVM scripting languages, in particular Python (CPython specifically).

To achieve this end goal I am working on a new module, /System/Launch, to allow me to explore that functionality. As a practical goal I am trying to use EASE to solve a long term problem of how to launch more complicated systems, especially those that run out of steam with the Launch Groups. For instance, multiple launches for debugging a multi-core system (especially with customizations and interdependencies) or parametrization of job launches.

Scripted Launch Group

As a starting point I want to simply re-create what Launch Groups can do in Javascript. So with EASE installed, including my new module, this is what a simple Launch Group replacement looks like.

The Launch Module

The Launch Module is a new module under consideration for EASE (Bug 478397). Its key method is the “launch” method which takes a Launch Configuration Name and an optional Launch Mode. The method then loads the named launch configuration and launches it, finally returning an ILaunch to allow future interaction with.

By using the launch method multiple times, with some additional control around it, allows complex launch sequences to be created.


For these examples I have already created three launch configurations for my individual tools (the name of the launch configuration is the quoted string in the bullet list):

  • “Prepare” – An External Tools configuration which prepares my test environment
  • “Server” – A PyDev supplied, Python Run configuration to launch my Python server
  • “Client” – A Java configuration to launch my Java client

Running The Examples

  1. Create three launch configurations named as above.
  2. Clone/Import “JavaScript Snippets” project. The examples are located in org.eclipse.ease.scripts git repository (or will be soon, follow Bug 478397 to find out more).
  3. Open the scripts in “Launch Module Examples” folder.
  4. Right-click on the desired script
  5. Choose Run As –> EASE Script

Alternatively paste the lines from the examples into the Rhino Script Shell console (as in the screenshot above). You get auto-completion of the names of the launch configurations and the launch modes too!

Example 1 – Fire and forget

In this first example, we simply launch the Client in Debug mode.


launch("Client", "debug")

Line 1: load the Launch module, this populates the namespace with all the methods defined in the Launch module.
Line 3: launch the existing launch configuration “Client” in debug mode.

Example 2 – Replicate Functionality from Launch Groups

In this example, we prepare our environment with the “Prepare” configuration, then launch the “Server” and “Client” configurations.


prepare = launch("Prepare")
while (!prepare.isTerminated()) {


launch("Client", "debug")

Line 1: load the Launch module
Line 3: launch the Prepare configuration
Line 4-6: Busy-wait until the Prepare launch has terminated[1]
Line 8: launch the server
Line 9: Wait 3 seconds for the server to be ready
Line 11: launch the client in Debug mode

Example 3 – Terminating the Server Automatically

Example 1 and 2 are a promising start, but do not yet add any new functionality to Eclipse. So what do you do if you want the server to stop automatically when you finish debugging your client. Well that is really easy now, just monitor the client launch and terminate the server.


prepare = launch("Program prepare")
while (!prepare.isTerminated()) {

server = launch("Python Server")

client = launch("Java Client", "debug")
while (!client.isTerminated()) {

Line 1-7: the same as Example 2
Line 8: launch the Server, but keep a handle of the ILaunch
Line 9: Wait 3 seconds for the server to be ready
Line 11: launch the Client
Line 12-14:Busy-wait until the Client debug session launch has terminated[1]
Line 15: terminate the server

This is a screenshot that shows what the Debug View looks like when we are busy-waiting on line 12.
At the top is the EASE Script launch of the example.
Then is the now terminated Prepare launch.
Followed by the still running Server in Run mode.
And finally, the Java Client, in Debug mode stopped at a breakpoint in main.

ease_launching_debug_viewTerminating the Server Automatically – Debug View

More Advanced Options

With the full power of the scripting language you can take these examples to the next step. A good place to start would be to remove the 3 second delay on Line 9 and replace that with some logic that actually determines if the server is ready to accept connections.

Other Functionality in the Launch Module

The Launch module is very new and I invite additional contributions to it to make it more useful. For now this is a quick overview of what it does:

String[] getLaunchConfigurationNames()

Returns an array of all the Launch Configuration Names known to the Launch Manager. These names can be used as the argument to the getLaunchConfiguration, launch and launchUI methods.

ILaunchConfiguration[] getLaunchConfigurations()

Returns an array of all the Launch Configurations known to the Launch Manager. These can be used as the argument to launch and launchUI methods.

ILaunchConfiguration getLaunchConfiguration(String name)

Return the launch configuration given by name parameter. The launch configuration can be edited or otherwise operated on. See ILaunchConfiguration.getWorkingCopy().

ILaunch launch(String launchConfigurationName, String mode)
ILaunch launch(ILaunchConfiguration configuration, String mode)

Launch the configuration either given by name or a launch configuration and return the ILaunch for further processing. This is the way to launch a configuration within a script which is itself launched.

ILaunch launchUI(String launchConfigurationName, String mode)
ILaunch launchUI(ILaunchConfiguration configuration, String mode)

Launch the configuration in the UI thread. This method respects the workspace settings for things like building before launching.

ILaunchManager getLaunchManager()

Obtain the platform launch manager. This allows access to the Eclipse debug core launch manager, allowing control over all non-UI aspects of launches. The most valuable of these should be wrapped for ideal script usage and made available in the module itself.[2]


1. A better API than busy-waiting is probably desired here, but that is for another day (and more Javascript knowledge).
2. Additional UI functionality is within the DebugUITools class, enabling access to this class directly from within the launch module is an option. Additionally, a Debug module would be very useful.

by Jonah Graham at October 04, 2015 03:01 PM