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

by Fabio Zadrozny ( 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 (

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 for more information on LiClipse and for PyDev.

by Fabio Zadrozny ( 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

CR1 for Eclipse Mars - more Docker, OpenShift and WildFly 10

by akazakov at October 05, 2015 07:54 PM

We are happy to announce JBoss Tools 4.3 CR1 and Red Hat JBoss Developer Studio 9 CR1 for Eclipse Mars are now available.

Note: Integration Stack tooling will become available from JBoss Central at a later date.

jbosstools jbdevstudio blog header
Remember that since Beta1 we require Java 8 for installing and using of JBoss Tools. We still support developing and running applications using older Java runtimes. See more in Beta1 blog.

What is new ?

The full details of what is new is available on this page. Some highlights are below.

WildFly 10 and EAP 7 Server Adapters

New server adapters for JBoss EAP 7 and WildFly 10 have been added to the toolset, allowing you to enjoy all the past benefits, but with all the newest runtimes.


Quick Access to Launch LiveReload

Users can now launch LiveReload from the &aposQuick Access&apos menu, or using the Ctrl+3 (or Cmd+3) keyboard shortcut.

This will first display the dialog to create and start a LiveReload server. Then, this will open the current element (a selected file in the Project Explorer, a selected module in the Servers view or the content of the active editor) in the browser, without even having to use the &aposOpen With>Web Browser via LiveReload Server&apos contextual menu.

livereload quick access

OpenShift 3

We have made great progress in the OpenShift 3 Eclipse Tooling, but a few features are still missing, like deploying an existing workspace project, or editing existing build configurations. We have some ideas to provide an even better OpenShift Explorer user experience.

OpenShift 3 tooling is provided as a TechPreview feature, available from the JBoss Central Software/Updates page. Once we are fully satisfied with the quality of its feature set, OpenShift 3 tooling will mature to a Supported feature in the upcoming months, and will then be installed by default in JBDS.

But despite the fact that OpenShift 3 is still in TechPreview status in this release there are many improvements. Such as enhancements in the Application wizard or a link to the online documentation from the connection wizard for OpenShift 3. Hopefully that should help you get started with OpenShift 3 in Eclipse:


Improvements in OpenShift Explorer:


Easy setup for &aposoc&apos binary and log streaming:


Integration with Docker tooling:


And other features + almost a hundred fixed bugs.

Java EE Batch Tooling

Quick Fixes for validation problems in Batch Job XML source editor.


The Quick Fixes open a pre-set New Batch Artifact wizard to create the missing artifact.

New Maven Red Hat GA repository

In the Maven Repository Configuration wizard, accessible from Preferences > JBoss Tools > JBoss Maven Integration > Configure Maven Repositories…​, the predefined Red Hat TechPreview All Maven repository has been replaced with the new, official Red Hat GA (GA: General Availability) repository, for released Red Hat JBoss Middleware artifacts.

It is recommended you replace the old TechPreview All repository with the new GA one, in your Maven settings.xml.

Offline Support for Project Examples in JBoss Central

In the updated JBoss Central page, you now have access to more than 200 project examples. All these examples and their dependencies can now be cached locally via the Groovy Offline script, available from Preferences > JBoss Tools > Project Examples > Offline Support.

Eclipse Mars.1 with better Docker tooling

This version of JBoss Tools targets Eclipse Mars.1 which besides many bug fixes has some noteworthy improvements such as a better Docker tooling. We worked on the Docker tooling to make it rock in JBoss Tools with OpenShift support - so we wanted to highlight these improvements.

Running/paused/stopped Docker containers

New icon decorators in Docker Explorer View show the state of the docker containers. This makes it clearer if a container is running, paused or stopped.


New Dialog to Search and Pull Images

There is an updated Pull Image wizard which can be launched from the Docker Images view or from the Docker Explorer view (a new context menu entry is available on the connection node and on the Images node):


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, he or she can click on the Search…​ button which will open the Search wizard:


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

New Launcher to Build a Docker Image

We have also added a new launcher to build images from a Dockerfile.


You can find more details about this and other new stuff in Docker tooling here.

What is Next

With CR1 out we are heading towards a final release.

Have fun!

Alexey Kazakov

by akazakov at October 05, 2015 07:54 PM

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 ( 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 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 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 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 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

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

by Christian Pontesegger ( 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

Meet me at Qt World Summit 2015 in Berlin

by ekkescorner at October 04, 2015 02:49 PM

Next days I’ll be at Qt World Summit in Berlin (2015-10-05 … 07)


I’ll also present a Lightning Talk on Tuesday with a Live Demo HowTo use Xtext /Xtend to generate C++/Qt Code for mobile BlackBerry 10 Business Apps.

There’s also a new Conference2Go Application for Qt World Summit to get all Infos on Sessions, Speaker, venue and more.


read more about this app here.

At Qt World Summit I’ll evaluate if using “Qt for Mobile Android” could be a way to support upcoming BlackBerry “Priv” Device and to re-use most from C++ business logic from BlackBerry 10. I’m generating most of this kind of stuff using my DSL (see above), so it would be fun to generate for two different platforms. Will blog about my findings later.

cu in Berlin or next month at EclipseCon Europe in Ludwigsburg, where I have some more time to demo my DSL live.

Filed under: BB10, C++, Cascades, EclipseCon, MDSD, mobile

by ekkescorner at October 04, 2015 02:49 PM

Xtext for IntelliJ IDEA - Preview

by Sven Efftinge ( at October 02, 2015 06:44 PM

Today we've released a preview version for the upcoming IntelliJ IDEA support of Xtext. With this it is now possible to develop Xtext languages entirely in IDEA and due to the cool Gradle support in any other environment, too.

The preview plugins for IntelliJ IDEA can be installed from the following repository location:

Note that Xtext requires the latest IDEA 15 Preview build.

I've recorded a small screencast that shows what Xtext in IntellijJ IDEA looks like:

by Sven Efftinge ( at October 02, 2015 06:44 PM

Handly 0.3.1 released

by Vladimir Piskarev at October 02, 2015 03:00 PM

I am pleased to announce the availability of the Handly 0.3.1 release. This service release addresses issues found in the 0.3 version.

by Vladimir Piskarev at October 02, 2015 03:00 PM

Download Eclipse Mars.1

October 02, 2015 03:00 PM

Eclipse Mars.1 has just been released and is available for download.

October 02, 2015 03:00 PM

WTP 3.7.1 Released!

October 02, 2015 10:00 AM

The Web Tools Platform's 3.7.1 Release is now available! Installation and update can be performed using the Mars Update Site at Release 3.7.1 fixes issues that occur in prior releases or have been reported since 3.7's release. WTP 3.7.1 is featured in the Mars.1 Eclipse IDE for Java EE Developers, with selected portions also included in other packages. Adopters can download the build itself directly.

More news

October 02, 2015 10:00 AM

Overriding a method in Eclipse IDE and (non-Javadoc) comment lines

October 02, 2015 07:44 AM

Almost everything is configurable in Eclipse. If the default values do not work for your project, you should invest time to tune your IDE. Yesterday a colleague told me about a configuration to change something I found annoying every day: By default, when you override a method in a child class in Eclipse you get something like this:

public class ViewDetailsButton extends AbstractExtensibleButton { 
 /* (non-Javadoc)
 * @see org.eclipse.scout.rt.client.ui.form.fields.button.AbstractButton#execClickAction() 
 protected void execClickAction() throws ProcessingException { 
 // TODO Auto-generated method stub 

I never understood why the "(non-Javadoc)" comment lines were generated and I always removed them. This is not really a big deal (moving the cursor, pressing CTRL+D, going back to the method body) and I could live with it. Now that I know that switching off the generation of those line can be configured, I ask myself why I did not did it sooner.

Under preferences, open the "Code Templates" preference page (under the Java code style). Select "Comments > Overriding methods" in the tree and click on the "Edit…" button. In the second Dialog you can edit the pattern.

October 02, 2015 07:44 AM

Eclipse Performance revisited

October 01, 2015 07:30 PM

With the release of Mars.1 and Neon.2 today, I thought it would be good to see what effect (if any) the optimisations that I’ve been working on have had. So I took Neon and Mars for a spin, and compared the outputs.

I’ve been timing the startup of an application with the org.eclipse.osgi/debug traces; specifically, the loader (which displays whenever a class is being loaded), and bundleTime (which measures the execution time of the Bundle-Activator). By running the application, then hitting the red stop button when the main window is available, it’s possible to get a measure of how fast the application starts up. I don’t do ‘quit’ from the application (because that would cause more classes to be loaded) so I just terminate the JVM at the right point.

However, to automate it, and to allow others to experiment as well, I invested in some time in creating various launch configurations pushed them to so that others could replicate my setup. Essentially, there’s an E4 application with no content, that starts up and then shuts down shortly afterwards. There are some external tools that can process these lists to give numbers that are hidden in the application.

That’s the good news. The bad news is that the optimisations so far haven’t had much of an effect; in fact, start-up of Neon is slightly slower than Mars at the moment. Starting an Eclipse SDK instance (the original SDK from as opposed to the EPP, so I can get measurements without automated reporting) led to a start-up time of Mars of around 6.1s and Neon of 6.3s.


In fact, the start-up of the empty project has remained around the same, at 1.8s (after files are in the cache). Strangely enough, if you look at the list of classes loaded there are a few more classes that are loaded (such as o.e.core.internal.content.BasicDescription and o.e.core.internal.content.ContentType) which weren’t there before. On the plus side, the total byte size has dropped slightly (about 4k) and we’re now down to 21 activators, from 30 before. This was counterbalanced by the activators' removal as well as a number of other inner classes; for example, the migration of inner classes to lambdas in Lars' commit was a reduction of the load of separate classes. (Lars, if you want to take another one then JobManager would be a good one, as would E4Application and WBWRenderer … but never mind that now.)

Now the additional .content. changes are suspicious, if only because I have pushed a few changes to that recently. I originally thought that the removal of static references were at fault, but it turns out that the move to declarative services caused the problem.

How can that happen, I hear you ask? Well, it’s a damn good question because it took me a while to work that out as well. And the other question – what to do about it – is also another interesting one as well :)

As a side-note, measuring performance of Eclipse at start-up is a little challenging. Unlike correctness testing (where you can run tests in the IDE) the performance of the application, for performance testing there’s a variation depending on whether you are running the code from a JAR or from a project in the workspace (different class loader resolutions are used; there are different paths which load the content if it’s a File or an InputStream, different mechanisms for accessing resources and the like). You can test some deltas before and after, but to test it for real installing it into a host workspace and restarting is the minimum requirement.

There’s also differences between the builds published by the Eclipse infra and ones that your code does; it has been signed, and often gone through the pack200 processing/unprocessing. So the code that ultimately gets delivered is not quite the same as you can test locally. Other minor differences include the version of the Java runtime and compiler as well as a whole host of other potential issues. It’s not as much of a science as trying to minimise the variations to determine testing.

Anyway; back to DS. The changes to the ContentTypeManager included changing the ExtensionRegistry listener to an instance method, and to use DS to assign it (instead of the prior Activator). Why does this single change cause additional classes to be resolved?

It turns out this is a side-effect of the way DS works. When a related service is set, DS looks up the method from the XML file and then uses getDeclaredMethod() to look it up. In this case, it runs something equivalent to ContentTypeManager.class.getDeclaredMethod("setExtensionRegistry"). This is not far off what it used to do before in the Activator. So why does this do anything different now?

Well, the main reason is the way that the Java reflection is implemented. Although the code calls the single variant getDeclaredMethod("name"), internally this expands to getDeclaredMethods() and then filters them afterwards. As a result, you’re not just getting your method; you’re getting all methods. This means that all classes defined as exceptions, parameters or return results in that class will subsequently be loaded even though they are completely unnecessary. Although they aren’t actually initialized (their static blocks aren’t run) the class objects need to be defined so that they have placeholder types in methods that we don’t even need. This will then recurse to super-interfaces and super-classes (but not their contents) which will result in the additional classes being lodaed.

So we traded off the loading of the single Activator class of 5k for four classes which are 54k in size. Oops. Not a sensible trade-off.

The advantage that DS gives us is that it’s not acquired until it’s first used. This should be a boon because it means that we can defer the cost of loading these more expensive classes until we really need it. And do we need a content type manager for an empty window?

Aargh. It’s another Activator. This time, it’s PlatformActivator calling InternalPlatform which calls Unfortunately, a ServiceTracker calling open() will then trigger the initialization of the very service that we’re trying to be lazy in instantiating. Sigh.

As a side note, this is why we need a Suppliers factory. Instead of having all these buggy references to eagerly activated ServiceTrackers, we should be delegating to a single implementation that would Do The Right Thing, including deferring opening the tracker until it’s been accessed for the first time. (It would also help Tom, who would in future be able to replace this implementation with other non-OSGi implementations, such as ServiceLoader or whatever might come out of Jigsaw.)

The alternative of course is to replace it with a bunch of DS components; either of these solutions would work. If we can defer the accessing of the IContentTypeManager service, then none of the classes would be loaded.

Unfortunately, there’s no way of fixing the JDK. The new DS specification permits installing services in fields (though I’m not sure if this is exposed in PDE’s DS implementation yet). This wouldn’t help in this particular instance because the setting of the extension registry needs side-effects, which aren’t visible if only a field is set. In addition, the getField() call will perform the same resolution; and there’s more likely to be more fields which are defined with implementation classes than methods (which should generally be interfaces).

We could split the implementation to reduce the number of declared methods; for example, having a ContentTypeManagerDS subclass that exposes the DS required methods may reduce the number of classes that need to be resolved. Another alternative is to have a delegate which implements the interface and forwards the implementation methods; but in this case, the IContentTypeManager is such a large interface (with several super-interfaces and nested types) that this doesn’t buy much. Or we could just revert the commits in this particular case.

The good news is that this doesn’t particularly affect the SDK; the content type manager is used there, and these classes are loaded. So in the real test – how long it takes to spool up the SDK – either of these implementations are likely to be loaded in any case. It’s only in the startup of a simple E4 application that you’re likely to notice the difference; and this has a potential solution with addressing the PlatformActivator and friends.

October 01, 2015 07:30 PM

OSGi enRoute 1.0!

by Peter Kriens ( at October 01, 2015 07:00 PM

On September 29, 2015, we finally released OSGi enRoute 1.0 ... The road has been longer than expected but we expanded the scope with IoT and a lot happened in the past year. So what is OSGi enRoute 1.0? If this blog is too long to read (they tell me millennials have a reading problem :-), then you could start with the quick start tutorial. OSGi enRoute is an open source project that tries to

by Peter Kriens ( at October 01, 2015 07:00 PM

IoT is Everywhere at EclipseCon Europe

by Ian Skerrett at October 01, 2015 03:23 PM

The best thing about the Eclipse IoT community is that that participants real IoT practitioners and IoT experts. Our face-2-face meetings bring together senior technical leaders that are working on the core technology that is powering the IoT solutions of the present and future. This is why I am looking forward to the upcoming Eclipse IoT meetings at  EclipseCon Europe on Nov. 2-5. It is going to be 3 days of IoT learning and discovery for anyone interested in building IoT solutions.

Day 1 – IoT Unconference

Monday, November 2 we will have the IoT Unconference. The unconference is split into two parts 1) update from each of the IoT projects and learning about potential areas of collaboration, 2) open discussions and guest speakers. We encourage presentations and topic from outside the Eclipse IoT community and topics relevant to the existing community. For instance, I am sure there will be lots of discussion about an IoT Server Platform. This is a great opportunity for exploration and discussion on key IoT technical issues.

Day 2 – IoT Day

Tuesday, November 3 we will be hosting the IoT Day. This is a 1-day event for anyone who wants to immerse themselves in understanding how to build IoT solutions. There will be sessions on IoT security, IoT data processing and analytics, open approaches to smart home, IoT hardware, and others. There will be speakers from Deutsche Telekom, Bosch, Eurotech, Relayr, Red Hat and others. The nice thing about the IoT Day is that you can register just for 1 day so you don’t need to dedicate an entire week. Of course, EclipseCon Europe attendees can attend any of the IoT Day sessions as well.

Day 3 – IoT Playground

Wednesday, November 4 will be the IoT Playground. This is where you can see real IoT practitioners show off their work.

More IoT at ECE

IoT will be throughout the entire EclipseCon Europe schedule. Two of the keynotes, from BOSCH and BMW, executives will spotlight these companies strategies for IoT. In addition to the IoT Day, there will be sessions on the oneM2M standard from Orange, Buidling Smart Grids with Eclipse IoT, session on Eclipse Concierge, a super small OSGi runtime for IoT, software update for IoT, embedded Java for IoT and what seems to be a great talk Demystifing the Smartness


If you are interested in learning about IoT and getting in-depth with the Eclipse IoT experts, then EclipseCon Europe is the place for you. Register today.

by Ian Skerrett at October 01, 2015 03:23 PM

Debugging PHP with Eclipse PDT: A WordPress Example

by support-octavio at October 01, 2015 03:01 PM

IntroductionIf you code PHP and are tired of fighting l […]

The post Debugging PHP with Eclipse PDT: A WordPress Example appeared first on Genuitec.

by support-octavio at October 01, 2015 03:01 PM

Tycho 12: Build source features

by Christian Pontesegger ( at October 01, 2015 01:48 PM

Providing update sites containing source code for developers is considered good style. Used in a target platform it allows developers to see your implementation code. This makes debugging far easier as users do not need to checkout your source code from repositories they have to find first.

Tycho allows to package such repositories very easily.

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 source update site project

Create a new project of type Plug-in Development/Update Site Project. Name it com.codeandme.tycho.releng.p2.source and leave all the other settings to their defaults. You will end up in the Site Manifest Editor of your site.xml file. Instead of editing this file by hand we will immediately delete site.xml and copy over the category.xml file from com.codeandme.tycho.releng.p2.

Mavenize the project the same way as we did in tutorial 5: set Packaging to eclipse-repository and add the project to com.codeandme.tycho.releng/pom.xml.

Step 2: Modify category.xml

Source plug-ins and features will be created by tycho on the fly, so we have no real projects in the workspace we could add with the Site Manifest Editor. Therefore we need to open category.xml with the Text Editor. Tycho does not care about the url property, so remove it. Feature ids need to be changed to <>.source.

If you like you can move all source features to a dedicated category:
<?xml version="1.0" encoding="UTF-8"?>
<feature id="com.codeandme.tycho.plugin.feature" version="1.0.0.qualifier">
<category name="source_components"/>
<category-def name="source_components" label="Developer Resources"/>
Step 3: Configure tycho source builds

To enable source builds we need to extend com.codeandme.tycho.releng/pom.xml a bit. The source below contains only the additions to our pom file, so merge them accordingly (full version on github).

<!-- enable source feature generation -->


<!-- provide plug-ins not containing any source code -->
<plugin id="com.codeandme.tycho.product" />



When building source plug-ins, tycho expects every plug-in project to actually contain source code. If projects do not contain source, we need to exclude them as we do on line 26.

After building the project we will end up with a p2 site containing binary builds and source builds of each feature/plug-in.

by Christian Pontesegger ( at October 01, 2015 01:48 PM

Tycho 11: Install root level features

by Christian Pontesegger ( at October 01, 2015 12:55 PM


Do you know about root level features?

Components installed in eclipse are called installable units (IUs). These are either features or products. Now IUs might be containers for other features, creating a tree like dependency structure. Lets take a short look at the Installation Details (menu Help / About Eclipse) of our sample product from tycho tutorial 8:

We can see that there exists one root level feature Tycho Built Product which contains all the features we defined for our product. What is interesting is, that the Update... and Uninstall... buttons at the bottom are disabled when we select child features.

So in an RCP application we may only update/uninstall root level features. This means that if we want to update a sub component, we need to create a new version of our main product. For a modular application this might not be a desired behavior.

The situation changes when a user installs additional components into a running RCP application. Such features will be handled as root level features and can therefore be updated separately. So our target will be to create a base product and install our features in an additional step.

Great news is, that tycho 0.20.0 allows us to do this very easily.

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: Identify independent features

Tycho will do all the required steps for us, we only need to identify features to be installed at root level. So open your product file using either the Text Editor or XML Editor. Locate the section with the feature definitions. Now add an installMode="root" attribute to any feature to be installed on root level.
<feature id="org.eclipse.e4.rcp"/>
<feature id="org.eclipse.platform"/>
<feature id="com.codeandme.tycho.plugin.feature" installMode="root"/>
<feature id="com.codeandme.tycho.product.feature"/>
<feature id="" installMode="root"/>
<feature id="org.eclipse.emf.ecore"/>
<feature id="org.eclipse.equinox.p2.core.feature"/>
<feature id="org.eclipse.emf.common"/>
<feature id="org.eclipse.equinox.p2.rcp.feature"/>
<feature id="org.eclipse.equinox.p2.user.ui"/>
<feature id="org.eclipse.rcp"/>
<feature id="org.eclipse.equinox.p2.extras.feature"/>

Make sure to update the tycho version to be used to 0.20.0 or above.

Nothing more to do, build your  product and enjoy root level features in action.

by Christian Pontesegger ( at October 01, 2015 12:55 PM

How to run your web server and MQTT WebSockets broker on the same port

by Benjamin Cabé at October 01, 2015 11:48 AM

I was just asked how one can deploy a similar setup as the MQTT sandbox, where MQTT over WebSockets is available on port 80, just like the rest of the website.

There are actually two ways of achieving this.

Mosquitto as the main frontend

It’s a little-known fact but together with built-in WebSockets support (added in version 1.4), Mosquitto also can act as basic HTTP server, and directly serve a bunch of static resources for you. The config option you’re looking for is “http_dir“, that will allow you to serve the content of a directory over HTTP.

Granted you are running a version of Mosquitto that has WebSockets support, here how your mosquitto.conf file should look like to enable WebSockets *and* regular HTTP connections:

listener 80
protocol websockets
http_dir /home/johndoe/htdocs

Of course, you will need to make sure that you do not have any other daemons (like Apache, nginx, …) already running and using port 80 :-)

Once Mosquitto is setup this way, you can use any MQTT client that supports WebSockets to connect to ws://yourhost URI.

ws://yourhost/ws, or ws://yourhost:80/foobar would work just fine too – Mosquitto doesn’t care about the path at all!

Apache front-end + mod_websocket_mosquitto

Since it’s likely you actually want a “real” HTTP server to serve your website (for security reasons, for being able to run PHP, etc.), another approach is to use Apache as the main HTTP front-end, as you would normally do, and configure it to tunnel WebSockets connections made on a given URI to your Mosquitto broker.

You can download an Apache module that does exactly that at The instructions to compile and install it are pretty straightforward and you will end up with something like the following in your Apache configuration:

<IfModule mod_websocket.c>
Loadmodule mod_websocket_mosquitto /usr/lib/apache2/modules/
 <Location /mosquitto>
 MosBroker localhost
 MosPort 1883
 SetHandler websocket-handler
 WebSocketHandler /usr/lib/apache2/modules/ mosquitto_init

by Benjamin Cabé at October 01, 2015 11:48 AM