Xtext 2.15 released!

by Xtext-Team (xtext@itemis.com) at September 20, 2018 01:00 PM

We are proud to announce Xtext and Xtend 2.15! As you can learn from the release notes (Xtext and Xtend), the focus of this release was on stability, quality and performance. Especially the Xtend Gradle build could be improved significantly and the integration with Eclipse 2018-09 works like a charm, now.

In the last three months, it turned out to be rather challenging to keep up with the new concept of rolling releases at Eclipse. We had to learn a lot and more than once we did this the hard way. In the end we are pretty satisfied with the outcome, though. And besides quite some fundamental groundwork on the process-side to get ready for the shorter 3 month release cadence, we did also find the time to squeeze in a few goodies that will make working with Xtext DSLs even more pleasant.

Bye bye Chunk 5 of 17

One of the noticeable adjustments, that we made, is the improved progress reporting. We redid the logic that tracks the remaining number of files during a build in Eclipse and are now issuing more fine grained feedback to the user. This was possible due to recent changes in the Eclipse platform. We do no longer face a performance degradation when reporting on such a granularity so it was about time to provide more insights on what's going on during a full build.


For the unit test addicted among us

Besides the fact that Xtext does now correctly mark test folders as such, when you create a new project, we are constantly working on improvements of the APIs for testing various Xtext services. This time, the infrastructure to test lexical and semantic coloring was added. It greatly simplifies testing of custom highlighting logic.


Also Xtend is now aware of the JUnit annotations and will flag methods with an invalid return type (read: non-void) already in the editor so you get immediate feedback if the type inference has computed some undesired return type for your test method. Especially when working with fluent test APIs this may be very handy.


There is more

The 2.15 release has more goodies that you can read about in the release notes of Xtext or Xtend. Being it the improved support for Task markers in Eclipse, the tweaks to the handling of files, that are external to your workspace, a command-line interface for creation of projects or new APIs in the core, make sure you do not miss some interesting bit or piece.

We value your feedback

As usual, if you face any issues with Xtext 2.15 or if you do have any other feedback, please don't hesitate to get in touch with us on GitHub, via the newsgroup or simply drop us a comment.

Contact the  itemis Xtext team

by Xtext-Team (xtext@itemis.com) at September 20, 2018 01:00 PM

Null/Undefined Analysis in N4JS

by Project N4JS (noreply@blogger.com) at September 20, 2018 12:39 PM

The N4JS IDE integrates validations and analyses that are quite common for IDEs of statically typed languages. However, these analyses are seldom available for dynamically typed languages like N4JS or TypeScript. In this post we present the null/undefined analysis for N4JS source code.

TypeError: Cannot read property of undefined
- Developer's staff of life

The runtime error above occurs pretty often for JavaScript programmers: A quick search on Google returned about 1.2 million for the term TypeError: Cannot read property of undefined. When constraining search results to site:stackoverflow.com the query will still yield 126 thousand results. These numbers are comparable to the somewhat similar error NullPointerException which has about 3 million hits on Google and about 525 thousand when constrained to stackoverflow.com. Some of these results are caused by rather simple mistakes that a null/undefined analysis could detect. As a result, the developer could restructure his code and remove these potential errors even before he runs his first test and hence save time.

Null/Undefined Analysis

The N4JS IDE provides static analyses to indicate problems when it detects a property access on a variable which can be null or undefined. The analysis considers all assignments that occur either through a simple assignment expression or via destructuring. Loops, conditional expressions (e.g. i = c? 1 : 0;) and declaration initializers are respected as well.

The screenshot above shows a first example where a potential TypeError is detected. Since there exists at least one control flow from v.length backwards to all reachable definitions of v,  such that one definition assigns null or undefined to v, a warning is issued telling that v may be undefined.

To make sure that the analysis will produce fast results, it is implemented within some limitations. One is that the analysis is done separately for each body of a function, method, etc. (i.e. intra-procedural analysis). Hence it lacks knowledge of variables that cross the borders of these bodies such as the return value of a nested function call. In addition, property variables (such as v.length) are not analyzed since this would require the analysis to be context sensitive to the receiver object (here v). However, these limitations are common for static analyses of statically typed languages and still allow to detect many problems regarding local variables and parameters.

Usually, the analysis makes optimistic assumptions. For instance it can happen that a local variable receives the value of a method call or another non-local variable. In this situation the analysis assumes this value is neither null nor undefined. The same is true for function parameters. Only when there are distinct indications in the source code for a value of a local variable to be null or undefined, the analysis will issue a warning.



Sometimes the programmer knows that a variable may be null or undefined and hence checks the variable explicitly, for instance using if (v) {...}. As a result this check disables the warning in the then-branch that complies to the execution semantics.

As shown in the screenshot above, neither at the expression w.length < 1 nor at the statement return w.length; a warning is shown. Of course, the else-branch of such a check would consequently always indicate a warning when a property of variable v is accessed. Checks for conditional expressions and binary logical expressions (e.g. v && v.length) are also supported. A reader might think: "In case w is null the expression w.length would fail." True, but in this example the analysis detects the value of w being undefined. In case null might have been assigned to w e.g. in an if-condition before, the analysis will issue a warning of w being null at the two w.length expressions.

Data Flow

There are situations where the value of a variable is null or undefined due to a previous assignment of a variable which may have been null or undefined before, like shown in the example above. Then, the null/undefined dereference problem occurs later when a property is accessed. Since the analysis respects data flow, it can follow the subsequent assignments. Hence a warning is shown at a property access indicating the null or undefined problem. Moreover, the warning also indicates the source of the null or undefined value which would be the variable w in the example above.

by Marcus Mews

by Project N4JS (noreply@blogger.com) at September 20, 2018 12:39 PM

Welcoming GlassFish to the Eclipse Foundation

September 19, 2018 07:30 PM

A major milestone was achieved yesterday! The GlassFish code from Oracle made its home in the Eclipse Foundation's Git repositories, starting a new era of Eclipse GlassFish.

September 19, 2018 07:30 PM

EMF Forms and EMF Client Platform 1.18.0 released!

by Jonas Helming and Maximilian Koegel at September 19, 2018 03:14 PM

We are happy to announce that with the Eclipse Release 2018-09, we have also shipped  EMF Forms and EMF Client Platform 1.18.0!

We want to thank our continuously active team of 11 contributors (41 contributors overall) for completing 50 bug fixes and features. EMF Forms continues to be one of the most active projects at Eclipse with a very stable development activity:

As announced during the 1.17.0 release, we have added a new service for adopters. The development team uses a defined  “Test” tag on important bug reports. In general, the “Test” keyword highlights bug reports, which should definitely be looked at and tested in detail by all adopters when updating to a new version. Please see more details in this announcement. All relevant “test” bug reports in 1.18.0 can be found here.

Please note, that due to the new release cadence of the Eclipse release train, there will be 4 releases per year for EMF Forms and EMF Client Platform from now on, too. As a consequence, we will be able to publish new features and improvements faster. The next release, 2018-12 is already due in December (19th).

Further, kindly continue to ask questions in the newsgroup and file Bug Reports.

In case you don’t know EMF Forms: It 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 an introduction.

Both of these frameworks are part of the Eclipse Modeling Tools Photon package, but you can also find the new release on our download pages:

As always, we will also blog about new features of the EMF Forms / ECP 1.18.0 release in the upcoming weeks! Please follow this blog or follow us on twitter for notifications about new posts.

by Jonas Helming and Maximilian Koegel at September 19, 2018 03:14 PM

Papyrus IC at Models 2018

by tevirselrahc at September 19, 2018 02:05 PM

It’s official! The Papyrus IC is a sponsor of Models 2018.

It’s members and users will be there to show me to anyone interested – Please go meet them so they don’t feel too alone out there!

I do not have the details yet, but I will be sure to pressure my minions to get me their game plans so I can let you all know!

by tevirselrahc at September 19, 2018 02:05 PM

Apache Camel Java DSL in combination Eclipse Kura Wires

by Jens Reimann at September 19, 2018 08:30 AM

In part #1 and part #2, we saw how easy it is to interface Apache Camel with Kura Wires. Simply by re-using some existing functionality. A few lines of XML, Groovy and you can already build an IoT solution based on the Camel ecosystem and the Eclipse Kura runtime. This part will focus on the Java DSL of Apache Camel.

It will also take into account, that when you develop and deploy an application, you need some kind of development, test and integration environment. When you build something, no matter how big, based on Camel or Kura Wires, you do want to test it. You want to have unit tests, and the capability to automatically test if your solution works, or still works after you made changes.

Using Kura Wires alone, this can be a problem. But Camel offers you a way to easily run your solution in a local IDE, debugging the whole process. You can have extra support for debugging Camel specific constructs like routes and endpoints. Camel has support for JUnit and e.g. using the “seda” endpoints, you can in create an abstraction layer between Camel and Wires.

The goal

I’ll make this one up (and yes, let’s try to keep it realistic). We have a device, and his device allows to set two parameters for its operation (P1 and P2, both floating points). Now we already have the device connection set up in Kura. Maybe using Modbus, or something else. Kura can talk to it using Kura Wires and that is all that counts.

Now we do get two additional requirements. There is some kind of operating panel next to the device, which should allow viewing and setting those parameters locally. Also, those parameters should be accessible, using IEC 60870-5-104, for an additional device, right next to the Kura gateway.

All of those operations have to be local only, and still work when no connection to the cloud is possible. But of course, we don’t want to lose the ability to monitor the parameters from our cloud system.

The operator panel will, of course, be programmed in the newest and hippest Web UI technology possible. It is super easy to fire a few HTTP API calls and encode everything in JSON. While, at the same time, the IEC 60870 layer has no idea about complex data structures. The panel application will send a full update of both parameters, while the 60870 client, due to the nature of this protocol, will only send one parameter at a time.

Doesn’t too unrealistic, does it?

The project structure

The full project source code is available at ctron/kura-examples, on GitHub. So this blog post will only focus on some important spots of the whole project.

The project is a standard Maven project, and thus has the typical project structure:

Maven Camel project structure

There are only three important differences to a standard Java Maven project:

The packaging type is bundle, which requires the maven-bundle-plugin. It will create an OSGi bundle JAR, instead of a plain JAR file. This is required as the Kura IoT gateway is based on OSGi.

We will create a “DP” package at the end of the build, using the OSGi DP Maven Plugin. This package can directly be uploaded to the Kura instance. As this plugin does include direct dependencies, but doesn’t include transient dependencies (on purpose), the project declares a few dependencies as “provided” to prevent them from being re-packaged in the final DP package.

The project uses the maven-antrun-plugin to download and unpack the static Swagger UI resources. Swagger UI is just a convenience for playing around with the REST API later on. Camel will take care of creating the OpenAPI (Swagger) JSON description, even if the SwaggerUI part is removed. So in a production setup, you most likely would not add Swagger UI to the deployment.

Starting it up

The project has three entry points:

  • CamelApplicationComponent is the OSGi service, which will be managed by the OSGi service component runtime (SCR) when the component is uploaded to Kura.
  • TestApplication is a local test application, which is intended to be started from the local IDE for manual testing.
  • CamelApplicationComponentTest is the JUnit 4 based test for testing the Camel routes.

All three entry points will have a slightly different creation process for the Camel Context. This is simply due to the fact that different environments (like plain Java, OSGI and JUnit) have different requirements.

The routes configuration, which is the same for all entry points, is located in Routes.

Let’s have a quick look at the OSGi startup:

public void start(final BundleContext context) throws Exception {
  this.context = new OsgiDefaultCamelContext(context, SwaggerUi.createRegistry());
  this.context.addRoutes(new Routes(this.state));

  final Dictionary<String, Object> properties = new Hashtable<>();
  properties.put("camel.context.id", "camel.example.4");
  this.registration = context.registerService(CamelContext.class, this.context, properties);

Once the component is placed inside an OSGi container, the start method will be called and set up the Camel context. This is all pretty straightforward Camel code. As the last step, the Camel context will be registered with the OSGi service layer. Setting the service property camel.context.id in the process. This property is important, as we will, later on, use it to locate the Camel context from the Kura Wires graph by it.

The Java DSL routes

The routes configuration is pretty simple Camel stuff. First, the REST DSL will be used to configure the REST API. For example, the “GET” operation to receive the currently active parameters:

  .description("Get the current parameters")

This creates a get operation, which is being redirected to the internal “direct:getParameters” endpoint. Which is a way of forwarding that call to another Camel Route. This way Camel routes can be re-used from different callers.

Like for example the `direct:updateParameters` route, which will be called by all routes which want to update the parameters, no matter if that call originated in the IEC 60870, the REST or the Kura Wires component:

  .bean(this.state, "updateCurrentParameters")
  .to("direct:update.wires", "direct:update.iec.p1", "direct:update.iec.p2").end();

The route will forward the new parameters to the method updateCurrentParameters of the State class. This class is a plain Java class, holding the state and filling in null parameters with the current state. The result of this method will be forwarded to the other routes, for updating Kura Wires and the two parameters in the IEC 60870 data layer.

Trying it out

If you have Java and Maven installed, then you can simply compile the package by running:

cd camel/camel-example4
mvn clean package

This will compile, run the unit tests and create the .dp package in the folder target.

You can upload the package directly to your Kura instance. Please note that you do need the dependencies installed in part #1 of the tutorial. In additional you will need to install the following dependencies:

  • https://repo1.maven.org/maven2/de/dentrassi/kura/addons/de.dentrassi.kura.addons.camel.iec60870/0.6.1/de.dentrassi.kura.addons.camel.iec60870-0.6.1.dp
  • https://repo1.maven.org/maven2/de/dentrassi/kura/addons/de.dentrassi.kura.addons.camel.jetty/0.6.1/de.dentrassi.kura.addons.camel.jetty-0.6.1.dp
  • https://repo1.maven.org/maven2/de/dentrassi/kura/addons/de.dentrassi.kura.addons.camel.swagger/0.6.1/de.dentrassi.kura.addons.camel.swagger-0.6.1.dp

This will install the support for REST APIs, backed by Jetty. As Kura already contains Jetty, it only makes sense to re-use those existing components.

Once the component is deployed and started, you can navigate your web browser to http://:8090/api. This should bring up the Swagger UI, showing the API of the routes:

SwaggerUI of Camel example for Kura

Next, you can create the following components in the Kura wires graph:

  • Create a new “Camel consumer”, named consumer2
    • Set the ID to camel.example.4
    • Set the endpoint URI to seda:wiresOutput1
  • Create a new “Logger”, named logger2
    • Set it to “verbose”
  • Connect consumer2 with logger2
  • Click on “Apply” to activate the changes

Open the console of Kura and then open the Swagger UI page with the Web browser. Click on ““Try Out” of the “PUT” operation, enter some new values for setpoint1 and/or setpoint2 and click on the blue “Execute” button.

In the console of Kura you should see the following output:

2018-09-17T13:35:49,589 [Camel (camel-10) thread #27 - seda://wiresOutput1] INFO  o.e.k.i.w.l.Logger - Received WireEnvelope from org.eclipse.kura.wire.camel.CamelConsume-1537188764126-1
2018-09-17T13:35:49,589 […] INFO  o.e.k.i.w.l.Logger - Record List content:
2018-09-17T13:35:49,589 […] INFO  o.e.k.i.w.l.Logger -   Record content:
2018-09-17T13:35:49,589 […] INFO  o.e.k.i.w.l.Logger -     P1 : 3.0
2018-09-17T13:35:49,589 […] INFO  o.e.k.i.w.l.Logger -     P2 : 2.0
2018-09-17T13:35:49,589 […] INFO  o.e.k.i.w.l.Logger -

This is the result of the “Logger” component from Kura Wires. Which did receive the new parameter updates from the Camel Context, as they got triggered through the Web UI. At the same time, the IEC 60870 server would update all clients being subscribed to those data items.

Wrapping it up

The last part of this tutorial showed that, if the prep-prepared XML router component of Eclipse Kura, is not enough, then you can drop in your own and powerful replacements. Developing with all the bells and whistles of Apache Camel, and still integrate with Kura Wires if necessary.

The post Apache Camel Java DSL in combination Eclipse Kura Wires appeared first on ctron's blog.

by Jens Reimann at September 19, 2018 08:30 AM

Welcoming GlassFish to the Eclipse Foundation

by Tanja Obradovic at September 19, 2018 12:45 AM

A major milestone was achieved yesterday! The GlassFish code from Oracle made its home in the Eclipse Foundation's Git repositories (https://github.com/eclipse-ee4j/glassfish), starting a new era of Eclipse GlassFish. This is another step in making Jakarta EE a vehicle for innovation in cloud-native application development.

The Eclipse GlassFish application server is still based on the Java EE specification, and we have a ways to go to finalize our work on defining necessary processes and approaches when working with open source TCKs. With the arrival of this codebase, we can start contemplating our first steps once we open up Jakarta EE for community contributions.

You can use the PMC’s project status page to track the progress we’re making in migrating all of the projects related to Jakarta EE.

Thanks to all involved in this effort, especially the Oracle team behind this move.

by Tanja Obradovic at September 19, 2018 12:45 AM

Papyrus UMLLight is go!

by tevirselrahc at September 18, 2018 12:57 PM

There were already a few posts [here] and [here] in which we talked about the new Papyrus UMLLight variant. Well – it is one step closer to completion.

My sources tell me that the scope has been defined and that requirements have been written, and that a request for quotation has been created and will soon be published!

Stay tuned for more information through official channels!

And of course, you will know about it here!

by tevirselrahc at September 18, 2018 12:57 PM

Special B2B Event at ECE

by Anonymous at September 17, 2018 07:36 PM

An Eclipse Foundation membership is a unique opportunity for smaller businesses. To encourage these organizations to join the Foundation, we are offering a special membership-plus-conference-attendance package.

Part of the package is a special business-to-business (B2B) event at the conference that offers a way for companies to expand both their commercial and development networks.

To learn more about this offering, please email Marc Vloemans, Eclipse Foundation Director, Ecosystem Development.

by Anonymous at September 17, 2018 07:36 PM

Call for BoFs

by Anonymous at September 17, 2018 06:03 PM

Birds of a Feather (BoF) sessions will be on Tuesday, 23 October, in the evening. If you are thinking of organizing a BoF, please visit this page for more information, and for access to the submission form for pre-scheduled BoFs.

by Anonymous at September 17, 2018 06:03 PM

Sunny weather with Apache Camel and Kura Wires

by Jens Reimann at September 17, 2018 02:48 PM

Part #1 of the Apache Camel to Kura Wires integration tutorial did focus on pushing data from Kura Wires to Camel and processing it there. But part #1 already mentioned that it is also possible to pull in data from Camel into Kura Wires.

Apache Camel consumer node in Kura Wires


For the next step, you again need to install a Camel package, for interfacing with Open Weather Map: https://repo1.maven.org/maven2/de/dentrassi/kura/addons/de.dentrassi.kura.addons.camel.weather/0.6.0/de.dentrassi.kura.addons.camel.weather-0.6.0.dp The installation follows the same way as already described in part #1.

In addition to the installation of the package, you will also need to create an account at https://openweathermap.org/ and create an API key. You can select the free tier plan, it is more than enough for our example.

Back to Wires

Next, create a new Camel context, like before, and give it the ID “camel2”. Add the required component weather, the required language groovy and set the following XML router content (be sure to replace <appid> with your API token):

<routes xmlns="http://camel.apache.org/schema/spring">


    <from uri="weather:dummy?appid=<YOUR API TOKEN>&amp;lat=48.1351&amp;lon=11.5820"/>
    <to uri="stream:out"/>

    <unmarshal><json library="Gson"></json></unmarshal>
    <convertBodyTo type="java.lang.Double"/>
    <to uri="stream:out"/>

    <transform><groovy>["TEMP": request.body-273.15]</groovy></transform>
    <to uri="stream:out"/>
    <to uri="seda:output1"/>



After applying the changes, you can create two new components in the Wire graph:

  • Create a new “Camel Consumer”, name it consumer1
    • Set the Camel context ID camel2
    • Set the endpoint URI seda:output1
  • Create a new “Logger”, name it logger1
    • Set it to “verbose”
  • Connect consumer1 with logger1
  • Click on “Apply” to activate the changes

What does it do?

What this Camel context does, is to first start polling information from the Open Weather Map API. It requests with a manually provided GPS location, Munich.

It then parses the JSON, so that we can work with the data. Then it extracts the current temperature from the rather complex Open Weather Map structure. Of course, we could also use a different approach and extract additional or other information.

The extracted value could still be a number, represented internally by a string. So we ask Camel to ensure that the body of the message gets converted to a Double. If the body already is a double, then nothing will be done. But, if necessary, Camel will pull in its type converter system and optionally convert e.g. a string to a double by parsing it.

Now the body contains the raw value, as a Java double. But we still have two issues with that. The first one is, that the value is in degree Kelvin. Living in Germany, I would expect degree Celsius 😉 The second issue is, that Kura Wires requires some kind of key to that value, like a Map structure.

Fortunately, we easily can solve both issues with a short snippet of Groovy: ["TEMP": request.body-273.15]. This will take the message (request) body, convert it to degree Celsius, and using this as a value for the key TEMP in the newly created map.

Checking the result

As soon as you apply the changes, you should see some output on the console, which shows the incoming weather data:

{"coord":{"lon":11.58,"lat":48.14},"weather":[{"id":801,"main":"Clouds","description":"few clouds","icon":"02d"}],"base":"stations","main":{"temp":297.72,"pressure":1021,"humidity":53,"temp_min":295.15,"temp_max":299.15},"visibility":10000,"wind":{"speed":1.5},"clouds":{"all":20},"dt":1537190400,"sys":{"type":1,"id":4914,"message":0.0022,"country":"DE","sunrise":1537160035,"sunset":1537204873},"id":2867714,"name":"Muenchen","cod":200}

Every change, which should happen every second, shows three lines. First the raw JSON data, directly from the Open Weather Map API. Then the raw temperature in degree Kelvin, parsed by Camel and converted into a Java type already. Followed by the custom Map structure, created by the Groovy script. The beauty here is again, that you don’t need to fiddle around with custom data structures of the Kura Wires system, but can rely on standard data structures likes plain Java maps.

Looking at the Kura log file, which is by default /var/log/kura.log, you should see some output like this:

2018-09-17T13:57:10,117 [Camel (camel-15) thread #31 - seda://output1] INFO  o.e.k.i.w.l.Logger - Received WireEnvelope from org.eclipse.kura.wire.camel.CamelConsume-1537188764126-1
2018-09-17T13:57:10,117 [Camel (camel-15) thread #31 - seda://output1] INFO  o.e.k.i.w.l.Logger - Record List content:
2018-09-17T13:57:10,118 [Camel (camel-15) thread #31 - seda://output1] INFO  o.e.k.i.w.l.Logger -   Record content:
2018-09-17T13:57:10,118 [Camel (camel-15) thread #31 - seda://output1] INFO  o.e.k.i.w.l.Logger -     TEMP : 24.57000000000005
2018-09-17T13:57:10,118 [Camel (camel-15) thread #31 - seda://output1] INFO  o.e.k.i.w.l.Logger -

This shows the same value, as processed by the Camel context but received by Kura Wires.

Wrapping it up

Now, of course, a simple logger component isn’t really useful. But as you might now, Kura has the ability to connect to a GPS receiver. So you could also take the current position as an input to the Open Weather Map request. And instead of using my static GPS coordinates of Munich, you could query for the nearby weather information. So this might allow you to create some amazing IoT applications.

Stay tuned for Part #3, where we will look at a Camel based solution, which can run inside of Kura, as well as outside. Including actual unit tests, ready for continuous delivery.

The post Sunny weather with Apache Camel and Kura Wires appeared first on ctron's blog.

by Jens Reimann at September 17, 2018 02:48 PM

Leveraging the power of Apache Camel in Eclipse Kura

by Jens Reimann at September 14, 2018 01:52 PM

With the upcoming version of Eclipse Kura 4, we will see some nice new features for the embedded Apache Camel runtime. This tutorial walks you through the Camel integration of Kura wires, which allows you to bridge both technologies, and leverage the power of Apache Camel for your solutions on the IoT gateway.

Kura Wires is a graph-oriented programming model of Eclipse Kura. It allows wiring up different components, like a Modbus client to the internal Kura Cloud Service. It is similar to Node-RED.

Apache Camel is a message-oriented integration platform with a rule-based routing approach. It has a huge eco-system of components, allowing to integrate numerous messaging endpoints, data formats, and scripting languages.

A graphical approach, like Kura Wires may be interesting for a single instance, which is manually administered. But assume that you want to re-deploy the same solution multiple times. In this case you would want to locally develop and test it. Have proper tooling like validation and debugging. And then you want to automatically package it and run a set of unit and integration tests. And only after that you would want to deploy this. This model is supported when you are using Apache Camel. There is a lot of tooling available, tutorials, training, books on how to work with Apache Camel. And you can make use of the over 100 components which Camel itself provides. In addition to that, you have a whole ecosystem around Apache Camel, which can extend this even more. So it is definitely worth a look.


As a prerequisite, you will need an instance of Kura 4. As this is currently not yet released, you can also use a snapshot build of Kura 3.3, which will later become Kura 4.

If you don’t want to set up a dedicated device just for playing around, you can always use the Kura container image and it e.g. with Docker. There is a short introduction on how to get started with this at the DockerHub repository: https://hub.docker.com/r/ctron/kura/

Starting a new Kura instance is as easy as:

docker run -ti ctron/kura:develop -p 8080:8080

The following tutorial assumes that you have already set up Kura, and started with a fresh instance.

Baby Steps

The first step we take is to create a very simple, empty, Camel Context and hook and directly hook up a Camel endpoint without further configuration.

New Camel Context

As a first step, we create a new XML Router Camel context:

  • Open the Kura Web UI
  • Click on the “+” button next to the services search box
  • Select the org.eclipse.kura.camel.xml.XmlRouterComponent factory
  • Enter the name camel1
  • Press “Submit”

New Camel Context Component

A new service should appear in the left side navigation area. Sometimes it happens that the service does not show up, but reloading the Web UI will reveal the newly created service.

Now select the service and edit the newly created context. Clear out the “Router XML” and only leave the root element:

<routes xmlns="http://camel.apache.org/schema/spring">

In the field “Required Camel Components” add the stream component. Click on “Apply” to activate the changes. This will configure the Camel context to have no routes, but wait for the stream component to be present in the OSGi runtime. The stream component is a default component, provided by the Eclipse Kura Camel runtime. The Camel context should be ready immediately and will be registered as an OSGi service for others to consume.

The Wires Graph

The next step is to configure the Kura Wires graph:

  • Switch to “Wire Graph” in the navigation pane
  • Add a new “Timer” component named timer1
    • Configure the component to fire every second
  • Add a new “Camel Producer” named producer1
    • Set the Context ID field of the component to camel1
    • Set the endpoint URI to stream:out
  • Connect the nodes timer1 and producer1
  • Click on Apply to activate the changes

If you look at the console of the Kura instance, then you should see something like this:


Note: If you are running Kura on an actual device, then the output might be in the file /var/log/kura-console.log.

What is happening is, that the Kura wires timer component will trigger a Wires event every second. That event is passed along to the Camel endpoint stream:out in the Camel context camel1. This isn’t using any Camel routes yet. But this is a basic integration, which allows you to access all available Camel endpoints directly from Kura Wires.

Producer, Consumer, Processor

In addition to the “Producer” component, it is also possible to use the “Consumer”, or the “Processor”. The Consumer takes events from the Camel context and forwards them to the Kura Wires graph. While the “Processor” takes an event from the Wire Graph, processes it using Camel, and passes along the result to Wires again:

For Producer and Consumer, this would be a unidirectional message exchange from a Camel point of view. The Processor component would use an “in”/”out” message exchange, which is more like “request/response”. Of course that only makes sense when you have an endpoint which actually hands back a response, like the HTTP client endpoint.

In the following sections, we will see that in most cases there will be a more complex route set up that the Camel Wire component would interact with, proxied by a seda Camel component. Still, the “in”, “out” flow of the Camel message exchange would be end-to-end between whatever endpoint you have and the Wires graph.

Getting professional

Apache Camel mostly uses the concept of routes. And while accessing an endpoint directly from the Kura Camel component technically works, I wouldn’t recommend it. Mainly due to the fact that you would be missing an abstraction layer, there is no way to inject anything between the Kura Wires component and the final destination at the Camel endpoint. You directly hook up Kura Wires with the endpoint and thus lose all ways that Camel allows you to work with your data.

So as a first step, let’s decouple the Camel endpoint from Kura Wires and provide an API for our Camel Context.

In the camel1 configurations screen, change the “Router XML” to:

<routes xmlns="http://camel.apache.org/schema/spring">
        <from uri="seda:input1"/>
        <to uri="stream:out"/>

Then configure the producer1 component in the Wire Graph to use the “Endpoint URI” seda:input1 instead of directly using stream:out.

If everything is right, then you should still see the same output on the Kura console, but now Wires and Camel are decoupled and properly interfaced using an internal event queue, which allows us to use Camel routes for the following steps.

One benefit of this approach also is that you can now take the XML route definitions outside of Kura and test them in your local IDE. There are various IDE extensions for Eclipse, IntelliJ and Visual Studio, which can help to work with Camel XML route definitions. And of course, there are the JBoss Tools as well ;-). So you can easily test the routes outside of a running Kura instance and feed in emulated Kura Wires events using the seda endpoints.


This first example already shows a common problem, when working with data, and even so for IoT use cases. The output of org.eclipse.kura.wire.WireEnvelope@3e0cef10 is definitely not what is of much use. But Camel is great a converting data, so let’s make use of that.

As a first step we need to enable the JSON support for Camel:

  • Navigate to “Packages”
  • Click on “Install/Upgrade”
  • Enter the URL: https://repo1.maven.org/maven2/de/dentrassi/kura/addons/de.dentrassi.kura.addons.camel.gson/0.6.0/de.dentrassi.kura.addons.camel.gson-0.6.0.dp
  • Click on “Submit”

After a while, the package de.dentrassi.kura.addons.gson should appear in the list of installed packages. It may happen that the list doesn’t properly refresh. Clicking on “refresh” or reloading the Web page will help.

Instead of downloading the package directly to the Kura installation you can also download the file to your local machine and then upload it by providing the file in the “Install/Upgrade” dialog box.

As a next step, you need to change the “Router XML” of the Camel context camel1 to the following configuration:

<routes xmlns="http://camel.apache.org/schema/spring">
        <from uri="seda:input1"/>
        <marshal><json library="Gson"/></marshal>
        <to uri="stream:out"/>

In the Kura console you will now see that we successfully transformed the internal Kura Wires data format to simple JSON:


This change did intercept the internal Kura wires objects and serialized them into proper JSON structures. The following step simply appends the content with a “newline” character in order to have a more readable output on the command line.

Transforming data

Depending on your IoT use case, transforming data can become rather complex. Camel is good at handling this. Transforming, filtering, splitting, aggregating, … for this tutorial I want to stick to a rather simple example, in order to focus in the integration between Kura and Camel, and less on the powers of Camel itself.

As the next step will use the “Groovy” script language to transform data, we will need to install an additional package using the same way as before: https://repo1.maven.org/maven2/de/dentrassi/kura/addons/de.dentrassi.kura.addons.camel.groovy/0.6.0/de.dentrassi.kura.addons.camel.groovy-0.6.0.dp

Then go ahead and modify the “Router XML” to include a transformation step, add the following content before the JSON conversion:

return  ["value": new Random().nextInt(10), "timer": request.body.identification ];

The full XML context should now be:

<routes xmlns="http://camel.apache.org/schema/spring">
        <from uri="seda:input1"/>
        return  ["value": new Random().nextInt(10), "timer": request.body.identification ];
        <marshal><json library="Gson"/></marshal>
        <to uri="stream:out"/>

After applying the changes, the output on the console should change to something like:


As you can see, we now created a new data structure, based on generated content and based on the original Kura Wires event information.

Off to the Eclipse Hono HTTP Adapter

Printing out JSON to the console is nice, but let’s get a bit more professional. Yes, Kura allows you to use its Kura specific MQTT data format. But what we want to send this piece of JSON to some HTTP endpoint, like the Eclipse Hono HTTP protocol adapter?

Camel has a huge variety of endpoints for connecting to various APIs, transport mechanisms and protocols. I doubt you directly would like your IoT gateway to contact Salesforce or Twitter, but using OPC UA, MQTT, HTTP, IEC 60870, might be a reasonable use case for IoT.

As a first step, we need to install Camel HTTP endpoint support: https://repo1.maven.org/maven2/de/dentrassi/kura/addons/de.dentrassi.kura.addons.camel.http/0.6.0/de.dentrassi.kura.addons.camel.http-0.6.0.dp

The next step requires an instance of Eclipse Hono, thankfully there is a Hono sandbox server running at hono.eclipse.org.

In the XML Router we need two steps for this. You can add them after the to element, so that we still see the JSON on the command line:

<setHeader headerName=”Content-Type”><constant>application/json</constant></setHeader>
<to uri="https4://hono.eclipse.org:28080/telemetry?authenticationPreemptive=true&amp;authUsername=sensor1@DEFAULT_TENANT&amp;authPassword=hono-secret"/>

The first step sets the content type to application/json, which is passed along by Hono to the AMQP network.

Yes, it really is http4://, this is not a typo but the Camel endpoint using Apache HttpClient 4.

You may need to register the device with Hono before actually publishing data to the instance. Also, it is necessary that a consumer is attached, which receives the data. Hono rejects devices publish data if no consumer is attached. Also see: https://www.eclipse.org/hono/getting-started/#publishing-data

If you are using a custom deployment of Hono using the OpenShift S2I approach, then the to URL would look more like:

<to uri="https4://hono-adapter-http-vertx-sec-hono.my.openshift.cluster/telemetry?authenticationPreemptive=true&amp;authUsername=sensor1@DEFAULT_TENANT&amp;authPassword=hono-secret"/>

Wrapping it up

What we have seen so far is that, with a few lines of XML, it is possible to interface with Kura Wires, and start processing data that was originally not supported by Kura, sending to a target that also isn’t supported by Kura. On for that we only used a few lines of XML.

In addition to that, you can test and develop everything in a local, confined space. Without having to worry too much about actually running a Kura instance.

In Part #2, we will have a look at ways to get data from Camel back into Kura Wires. And in Part #3 of this tutorial, we will continue with this approach and develop a Camel based solution, which can run inside of Kura, as well as outside, including actual unit tests.

The post Leveraging the power of Apache Camel in Eclipse Kura appeared first on ctron's blog.

by Jens Reimann at September 14, 2018 01:52 PM

Sponsor testimonial: Jonas Helming on EclipseSource @ EclipseCon

by Anonymous at September 14, 2018 11:54 AM

Learn more about the EclipseSource contributions to the program on themes such as the Eclipse Theia platform, modeling tools, Eclipse 4 and general web-related topics.

Q - If you had to choose a theme to watch at the conference, what would it be?

A new trending topic at EclipseCon is definitely the growing interest into web-based tools. It is interesting for projects, whether web-based tooling is already a valid alternative and if so when and how to migrate. A lot of this interest is focussed around Eclipse Theia ..

by Anonymous at September 14, 2018 11:54 AM

An $8.7 Billion Shared Investment: Sizing the Economic Value of Eclipse Community Collaboration

September 13, 2018 02:30 PM

What is the value of the code contributed by the Eclipse community? We estimate that the roughly 162 million total physical source lines of code in Eclipse repositories represent a $8.7 billion USD shared technology investment by our community.

September 13, 2018 02:30 PM

JBoss Tools 4.9.0.AM3 for Eclipse 2018-09 M2

by jeffmaury at September 13, 2018 09:39 AM

Happy to announce 4.9.0.AM3 (Developer Milestone 3) build for Eclipse 2018-09 M2.

Downloads available at JBoss Tools 4.9.0 AM3.

What is New?

Full info is at this page. Some highlights are below.


Server Tools

Wildfly 14 Server Adapter

A server adapter has been added to work with Wildfly 14. It adds support for Java EE 8.

Forge Tools

Forge Runtime updated to 3.9.1.Final

The included Forge runtime is now 3.9.1.Final. Read the official announcement here.

Fuse Tooling

Know issues

A regression has been introduced touching all functionalities using Jaxb. It includes:

  • Variable content display in debug

  • Data Transformation wizard

  • Tracing Camel route via Jolokia Connection

It may affect other functionalities. In this case, you will have this kind of error in log:

          at javax.xml.bind.ContextFinder.handleClassCastException(ContextFinder.java:95)

Please note that it has been already fixed on nightly build


Jeff Maury

by jeffmaury at September 13, 2018 09:39 AM

Introducing our keynote speakers

by Anonymous at September 12, 2018 10:04 AM

Hirash Pillay, Global Head, Community Architecture and Leadership at RedHat - Lessons on Open Source from a 25-Year-Old Company

Tony Walsh, European Space Agency and Hristo Indzhov, Telespazio-Vega Deutschland - Flying to Jupiter with OSGi

Amanda Whaley, Director of Developer Experience & Developer Advocacy for Cisco DevNet -  Marie Curie, Open Source, Kickstarter, and Women in Tech

by Anonymous at September 12, 2018 10:04 AM

Sponsor Testimonial: Renesas

by Anonymous at September 12, 2018 09:50 AM

Renesas has been developing our own Eclipse based IDE product now for over 8 years for Embedded Developers using Renesas hardware. Last year was our first with a booth and this gave us a great opportunity to show the attendees what we are doing and really get to meet members of the community. Be sure to visit our booth this year for a look at our OpenADx autonomous driving simulation technology demonstrator!

by Anonymous at September 12, 2018 09:50 AM

How to deploy Eclipse Theia on a Raspberry Pi

by Jonas Helming and Maximilian Koegel at September 12, 2018 09:49 AM

Eclipse Theia is a platform to create IDEs and custom (modeling) tools based on  web technology (Typescript, CSS and HTML). Please see this article for details about this new Eclipse project.

One advantage of using web technology and more in particular Eclipse Theia is that the tool can then be accessed directly in the browser without any installation or client set-up. However, this only works, if the tool based on Theia has been deployed somewhere. This could be a cloud server, a docker container, or in our case a Raspberry Pi! You might wonder why you would want to deploy a browser tool on a Raspberry Pi. First of all, a Raspberry is probably the cheapest server you can imagine, so if, for whatever reason, you cannot deploy and access your tool in the cloud, a Raspberry still allows a local client/server deployment. More interestingly, Raspberry Pis are often used to control or orchestrate embedded use cases. That means, the Raspberry executes some software which can control devices that are connected to it. In this scenario, having the tooling to develop this software running on the Raspberry provides a very consistent set-up. You could then ship a Raspberry which includes the software and the tooling –  all on one device.

Anyway, since when do we need a reason to deploy something on a Raspberry Pi? It is just fun, so let us get going!

How to deploy Eclipse Theia on a Raspberry Pi

At this point we assume that you already installed the runtime dependencies of Theia, namingly Node.js v8 and Yarn.

The main issue we will have to deal with is a mismatch of processor architectures. The Raspberry Pi is powered by an ARM processor, while your development machine is likely an x86 based architecture. While it is certainly possible to build Theia directly on the Raspberry, you might want to instead use your regular computer for this. Doings so will save you the hassle of setting up the full build environment on the Raspberry and compilation will also be much faster.

However, you cannot simply copy your Theia build from a x86 based machine onto the Raspberry. This might seem odd at first because after all it is JavaScript based. However, Theia uses certain interfaces to make use of native OS functionality. For example, the terminal feature is based on the node-pty module, which forks native OS processes in the background and redirects their output. These interfaces include some C or C++ code, which must be compiled for the architecture Theia is running on. To be able to build code for the ARM architecture on your regular x86 machine you need a so called “cross-compiler”. As the name implies it will allow you to compile code for a target architecture that is different from the architecture the building machine itself is running on. The Raspberry Linaro provides a cross-compiler which you can find here. Clone this repository as a preparation and point the paths to it later (see below).

First, compile Theia as usual using

yarn install

This will build Theia for your current architecture (x86). Now we need to re-compile the native bits using our cross compiler. To do that we have to set two environment variables, defining the C and CPP compiler to use. You can set them like so:

export CC=/opt/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/arm-linux-gnueabihf-gcc
export CXX=/opt/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/arm-linux-gnueabihf-g++

Make sure to accordingly adapt the locations to your installation.

Afterwards, you need to run the following command line in the Theia project root directory to re-compile the native code parts for a

npm rebuild --target_arch=arm

Finally, unset the cross-compiler using:

unset CC CXX

That’s it! Copy your project directory onto your Raspberry and start it as usual:

Note: There is currently a time out issue when running Theia on a slow machine like a Raspberry Pi. You can avoid this problem by appending –no-cluster to the yarn start command. With this option, everything will run in the same process rather than separate worker processes. The progress of this issue is being tracked here.

by Jonas Helming and Maximilian Koegel at September 12, 2018 09:49 AM

JBoss Tools 4.9.0.AM2 for Eclipse 2018-09 M2

by jeffmaury at September 12, 2018 06:24 AM

Happy to announce 4.9.0.AM2 (Developer Milestone 2) build for Eclipse 2018-09 M2.

Downloads available at JBoss Tools 4.9.0 AM2.

What is New?

Full info is at this page. Some highlights are below.


Eclipse 2018-09

JBoss Tools is now targeting Eclipse 2018-09 M2.

Fuse Tooling

WSDL to Camel REST DSL improvements

The version of the library used to generate Camel REST DSL from WSDl files has been updated. It now covers more types of WSDL files. See https://github.com/jboss-fuse/wsdl2rest/milestone/3?closed=1 for the list of improvements.

REST Editor tab improvements

In the last milestone we began adding editing capabilities to the read-only REST tab to the route editor we added in the previous release. Those efforts have continued and we now have a fully editable REST tab.

Fully Editable REST Editor

You can now:

  • Create and delete REST Configurations

  • Create and delete new REST Elements

  • Create and delete new REST Operations

  • Edit properties for a selected REST Element in the Properties view

  • Edit properties for a selected REST Operation in the Properties view

In addition, we’ve improved the look and feel by fixing the scrolling capabilities of the REST Element and REST Operations lists.


Jeff Maury

by jeffmaury at September 12, 2018 06:24 AM

EC by Example: InjectInto

by Donald Raab at September 12, 2018 12:39 AM

Learn one of the most general, flexible, and least understood iteration patterns in Eclipse Collections.

Grounds for Sculpture, Hamilton N.J.

Continuum Transfunctioner

Like the Continuum Transfunctioner from “Dude, Where’s my car”, the method injectInto is a very mysterious and powerful method, and its mystery is only exceeded by its power.

So what does injectInto do?

The method injectInto can be used to do pretty much anything. The method injects an initial value into a two argument function along with the first element of the collection, and calculates some result. That result is then passed to the next invocation of the function as the initial value along with the next element of the collection. And so on and so forth until all elements of the collection have been visited and a final result is returned.

The name injectInto is based on the inject:into: selector from Smalltalk. InjectInto is an alternative name for foldLeft or reduce.

I will illustrate ways to implement various algorithms using injectInto to show how mysterious and powerful it is.

Example: Min and Max

public void injectIntoMinAndMax()
MutableList<Integer> list = Lists.mutable.with(1, 2, 3, 4, 5);

Integer maxInt = Integer.MAX_VALUE;
Integer minValue = list.injectInto(maxInt, Math::min);
Assert.assertEquals(list.min(), minValue);

Integer minInt = Integer.MIN_VALUE;
Integer maxValue = list.injectInto(minInt, Math::max);
Assert.assertEquals(list.max(), maxValue);

Example: Sum

public void injectIntoSum()
MutableList<Integer> list = Lists.mutable.with(1, 2, 3, 4, 5);

Integer sum = list.injectInto(Integer.valueOf(0), Integer::sum);
    Assert.assertEquals(Integer.valueOf(15), sum);

Example: Product

public void injectIntoProduct()
MutableList<Integer> list = Lists.mutable.with(1, 2, 3, 4, 5);

Integer product =
(result, each) -> result * each);
    Assert.assertEquals(Integer.valueOf(120), product);

Example: Collect

public void injectIntoCollect()
MutableList<String> lowerCase =
Lists.mutable.with("a", "b", "c", "d", "e");
    MutableList<Object> upperCase =
(list, each) -> list.with(each.toUpperCase()));

Example: GroupBy

public void injectIntoGroupBy()
MutableList<Integer> list = Lists.mutable.with(1, 2, 3, 4, 5);
    MutableListMultimap<Integer, Integer> grouped = 
    list.injectInto(grouped, (multimap, each) -> {
multimap.put(each % 2, each);
return multimap;
    Assert.assertEquals(list.groupBy(each -> each % 2), grouped);

Example: Collectors.groupingBy

public void injectIntoGroupingBy()
MutableList<Integer> list = Lists.mutable.with(1, 2, 3, 4, 5);
    MutableMap<Integer, List<Integer>> grouped =
    list.injectInto(grouped, (map, each) -> {
map.getIfAbsentPut(each % 2,Lists.mutable::empty)
return map;
Collectors.groupingBy(each -> each % 2)),

Example: Detect

public void injectIntoDetect()
MutableList<Integer> list = Lists.mutable.with(1, 2, 3, 4, 5);
    Integer value = list.injectInto(
(result, each) ->
result == null && each > 2 ? each : result);
    Assert.assertEquals(list.detect(each -> each > 2), value);

Example: Select

public void injectIntoSelect()
MutableList<Integer> list = Lists.mutable.with(1, 2, 3, 4, 5);
    MutableList<Integer> value = list.injectInto(
(result, each) ->
each % 2 == 0 ? result.with(each) : result);
    Assert.assertEquals(list.select(each -> each % 2 == 0), value);

APIs covered in the examples

  1. injectInto — applies a two argument function to each element of a collection using an initial value, and then injecting the result of each application of the function into the next iteration.

Check out this presentation to learn more about the origins, design and evolution of the Eclipse Collections API.

Eclipse Collections is open for contributions. If you like the library, you can let us know by starring it on GitHub.

by Donald Raab at September 12, 2018 12:39 AM