RAP 3.1 Supports Right-to-Left Orientation

by Ralf Sternberg at October 13, 2015 11:44 AM

Some languages, such as Arabic and Hebrew, are written from right to left. The different reading direction not only affects texts, but most UI elements. Preparing software for use in those languages obviously requires a lot more work than just translating texts. We’re currently adding right-to-left (a.k.a. “RTL”) support in RAP.

For example, if you check the Wikipedia in Hebrew, you’ll find the globe logo and the table of contents at the right, the tabs start on the right, while the search box moved to the left side. In short, the entire UI is mirrored:

Hebrew Wikipedia

You may notice that the scrollbar is still on the right. That’s because my browser is English. On an Arabic system, the scrollbar would also be on the left.

The mirroring not only affects layouts, also the widgets need to be drawn differently–like the search box in the screenshot above that has the search icon on the left. SWT supports right-to-left orientation using the SWT.RIGHT_TO_LEFT style flag. To support this style flag in RAP, we need to adjust all widgets. The most challenging widget is Tree, where not only the columns are reversed, but also the collapse and expand symbols are moved to the right edge:

Tree RTL

Right-to-left support will be complete in the next milestone, RAP 3.1 M3. Large parts are already available in M2, including the Tree.


Leave a Comment. Tagged with eclipse, New, new and noteworthy, rap, eclipse, New, new and noteworthy, rap

by Ralf Sternberg at October 13, 2015 11:44 AM

Yakindu Statechart Tools Survey - Intermediate Results

by Andreas Mülder (noreply@blogger.com) at October 13, 2015 10:51 AM

Ten days ago we started a short survey about YAKINDU Statechart Tools to get a better understanding what we have to improve and which features we should implemement next. The survey is still online - so if you are a Statechart Tools user and could spend 5 minutes to complete that'd be great. 

Begin Survey

Thanks to all the participants so far! Let us have a detailed look at the survey results. For all those nitpickers out there who notice that the overall sum is above 100 % for some questions - this is because multi selection was allowed ;).

Working area and kind of software

More than half of the survey participants work in the Industry area and want to use YAKINDU Statechart Tools for their commerical products. Nearly the same amount of users work in the Research (30%) and Education (20%) domain. Nice to see that there are also some people using YAKINDU for their Private projects just for fun. I would love to hear from you and the stuff you are building with Statechart Tools, just drop me an email or leave a comment!

The majority of all respondents want to develop software for Embedded Systems (70 %) and Human-Machine-Interfaces (40 %) as well as Automation Software (35%). About 20 % want to use Statechart Tools for Enterprise Software, Web Applications and Mobile Applications. Until this time, Statechart Tools are not used in the area of game development.

Experience with Statemachines and other Statechart Tools

24 % of the overall respondents state that they never used statemachines before. 60 % use statemachines from time to time and no fewer than 16% call themselfs statemachine experts. Nearly 50 % worked with other Statemachine Tools before using YAKINDU Statechart Tools. Most popular Statemachine Tools mentioned are Matlab Stateflow, Enterprise Architect, IAR Visual State, SCADE and Rational Rhapsody.

Why are you using YAKINDU Statechart Tools?

The majority of all users want to generate C code out of their statemachines (65%), while 50 % want to generate Java and C++ Code. At least 24% of our users want to generate code for other programming languages, most mentioned Javascript, Phyton and VHDL.

About 24 % of our users use YAKINDU Statechart Tools to learn about statecharts, 13 % of them also want to teach statecharts. But the majority (58%) want to develop software and want to use it for system modeling (40%). Really surprising to me was the fact that nearly 30 %' of all participants 'care about modeling toolchains and want to integrate' SCT in their IDE. This is fairly easy - thanks to open source and the underlying Eclipse Platform.

How do you rate the tool and what can we improve?

Last but not least we asked our users how they rate different aspects of YAKINDU Statechart Tools on a scale from 1 (poor) to 4 (perfect). As you can see in the diagram on the left, the average rating for Graphical Editing, Simulation,Validation, Code Generation and Usability is 3 (good). Of course, 'good' is not good enough, we will further improve these tool features. 

Only Documentation & Tutorials was rated with an average of 2 (does the job). We will improve the documentation in the future and we are also planning an ebook with additional examples.
The 'feature-wish' section of our survey was a great source of inspiration for us. Of course, we can not implement all those cool features at once, but we are open for external contributions. If  you want to integrate a model checker like UPPAAL (someone is already prototyping this), or add an importer for stateflow or other features just fork us on GitHub!

by Andreas Mülder (noreply@blogger.com) at October 13, 2015 10:51 AM

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

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