Codetrails Announces Seed Investement by High-Tech Gründerfonds

by Marcel Bruch at November 28, 2014 01:10 PM

Big Data Makes Life Easier for Software Developers

Software systems not only pervade more and more industries, but they are also growing more and more complex. But regardless of whether software developers have to understand yesterday’s legacy systems or tomorrow’s hot technologies, one question is always the same: How do I tell the machine what to do? Using Big Data, the young company Codetrails GmbH answers this question for Java developers. High-Tech Gründerfonds funds the spin-off of TU Darmstadt to further Codetrails’ capabilities of automated knowledge transfer and bug detection.


by Marcel Bruch at November 28, 2014 01:10 PM

Simply the Best

by Ralph Mueller (noreply@blogger.com) at November 28, 2014 12:59 PM

My dear colleague Roxanne has assembled the list of the top-ten talks from EclipseCon Europe 2014.
And here they are:

1. What every Eclipse developer should know about Eclipse 4 (e4)
Jonas Helming and Eugen Neufeld

2. Stop clicking, be productive – Exploiting postfix templates
Nicolaj Joess

3. New and Noteworthy in Xtend
Sebastian Zarnekow and Stefan Oehme

4. Eclipse Platform Localization - The Luna Updates
Dirk Fauth

5. How to cook an egg with the Eclipse Communication Framework and Nebula.
Wim Jongman

6. Lambda Mechanics
Marc R. Hoffmann

7. Enhanced Tooling for Modern Eclipse Plugin Development
Mikael Barbero

8. Oomph: Automatically Provision a Project-specific IDE
Eike Stepper and Ed Merks

9. 10 Platforms in 30 minutes - powered by Eclipse
Jonas Helming and Maximilian Koegel

10. Building Business UIs with EMF Forms
Maximilian Koegel

Looks like the team prize goes to EclipseSource Munich. Congrats, team!

If you missed the talks, refer to our Youtube channel. Uploading of the talks continues!
 

by Ralph Mueller (noreply@blogger.com) at November 28, 2014 12:59 PM

Multi Column SmartField

by Jérémie Bresson at November 28, 2014 08:07 AM

During the Scout User Group Meeting each participant has presented how he was using Eclipse Scout. It was nice to see that many of them were already using a new feature introduced with Luna: Multi-Column SmartField.

Scout Multi-Column SmartField

SmartField to select a position in the Swiss train network.

One day later, during the EclipseCon Europe another Eclipse Scout user told me he missed the announcement of this new feature. We had some documentation on the SmartField wiki page. But I agree with him, adding a few lines in a wiki page is not the best way to make the community aware of what is new with Luna.

It is never too late to communicate about a feature. ;-)

The mistake is now fixed:

We are proud of this new feature for these reasons:

  • SmartField are used in a lot of Scout applications (we presented this feature during the EclipseCon Europe 2011: Eclipse Scout – Discover the Potential).
  • Having multiple columns is a natural addition to the framework.
  • The feature was sponsored by two of our customers.

We still have some work to do in the Scout SDK: with Luna, you will need to write the code yourself; there is no wizard or no property view support for this task (See Bug 423802 for the enhancement request in the SDK).

Scout Links

Project Home, Forum, Wiki, Twitter


by Jérémie Bresson at November 28, 2014 08:07 AM

SwitchYard Service Debugger

by ldimaggio at November 27, 2014 03:11 PM

This post introduces the new service debugger for JBoss SwitchYard and provides the reader with an overview of SwitchYard’s capabilities, as demonstrated in its example “quickstart” programs.

To install this feature in Developer Studio 8 and JBoss Tools 4.2 you should enable 'Early Access' in Central and install the 'JBoss Integration and SOA Development' connector. See more in the Integration Stack Beta release blog.

Introduction

One of the most useful (and by the way, also one of the coolest) features of JBoss SwitchYard (http://switchyard.jboss.org/) is its graphical process editor. The editor enables you to create composite service definitions through a graphical interface, instead of having to directly edit cumbersome raw XML. For example:

debugger 1

The big blue box in the center window is called the canvas. Here’s where you can see the graphical representation of the service definition. With SwitchYard, it’s all about the services. With the SwitchYard editor, you can create the services, and not just edit Java source code.

What’s always been missing has been a corresponding tool for debugging SwitchYard Services. This gap is now being filled by the SwitchYard Debugger.

The SwitchYard Debugger

A debugger such as GDB provides you with the ability to interrupt a program’s execution through breakpoints so that you can examine code and data. In SwitchYard, however, you’re not just dealing with Java classes, you 're creating (and debugging) services. The SwitchYard debugger lets you add a breakpoint to any service or reference to a service. The debugger supports these actions:

  • Breakpoints can be configured to stop at various points in the execution chain, including service entry or transaction setup (entry, teardown, fault).

  • If you add a breakpoint on a service, the breakpoint will trigger for any reference or composite service invoking that service. In contrast, if you add a breakpoint on a service reference, it will only break when that reference is invoked.

  • You can also set breakpoints on a composite service to debug validators and transformers (both inbound and outbound). You would do this if you want to see what’s going through a particular transformer or validator which may be used by a number of interactions.

  • If you configure a breakpoint to break on transactions, it will break into the SwitchYard TransactionHandler.handleMessage() method. This generates a stack trace that includes SwitchYard details (for example, an Exchange) that are visible in the SwitchYard context view, so that you can examine elements such as message contents and context properties.

In contrast to a Java debugger, the SwitchYard debugger enables you to invoke breakpoints during steps (such as transformation) during the execution of the service, right in the service bus:

  • Breakpoints on component services and composite references (in other words, providers) will break anytime they are invoked, regardless of who is calling them.

  • Breakpoints on composite services and component references (in other words, consumers) will break whenever they call out.

  • So, if you’re having a problem with a service, putting a breakpoint in the service, will allow you to see what’s going in or out. If you’re having a problem with a component or endpoint, putting a breakpoint on a consumer will allow you to see what’s going in/out, and where it’s going.

  • With regard to the locations within a service (for example, transformation), if you have a specific problem, such as if you’re seeing policy exceptions or transactions aren’t working the way you expect, you can set it to break during the policy phase or the transaction phase to see just what’s going on (which policies are required, which are provided).

The best way to understand the new debugger is to see it in action. We’ll do this by using the debugger with SwichYard "quickStart" example programs. Let’s get started!

Getting SwitchYard

Before we can see the debugger in action, we have to install the SwitchYard runtime and its corresponding Eclipse tooling. Luckily, downloading and installing JBoss software* is quick and painless (and free!)

The steps to install the SwitchYard runtime are:

The steps to install SwitchYard’s Eclipse tooling are:

(We’re using the latest versions of the software available when this post is being written.)

The Quickstarts

One of the helpful features included with JBoss projects are example programs referred to as “quickstarts.” As the name implies, the goal of these examples is to help users get started quickly in learning technologies provided by JBoss projects. As we mentioned earlier in this post, the approach that we’ll take is to introduce a bugs into quickstarts, and then use the debugger to locate these bugs.

To introduce SwitchYard applications to new users, we’ll examine the first quickstart that we’ll use in some detail. If you are already familiar with SwitchYard applications, you can skip over this section of the post.

Let’s start by using the debugger to interrupt a running service in a quickStart and enable us to examine the data in a message being processed by the service. After this, we’ll take things one step further and introduce a bug into a service and then use the debugger to find the cause of the bug and work around it.

Looking under the Hood of a Quickstart

Before we examine how the debugger can be used with a quickStart we’ll take a look at how quickstarts are implemented and how to use the SwitchYard editor.

The first quickstart that we’ll run makes use of Apache Camel to implement content based routing to route messages to selected services. This quickstart is aptly named: rules-camel-cbr. Before we run the quickstart, let’s take a quick look at how it works.

To understand how the quickstart is constructed and how it works, we’ll examine it by looking at these 3 elements:

  • The quickstart’s service based design. We’ll look at this through the SwitchYard visual editor.

  • SwitchYard’s integration of camel routes with the quickstart’s services.

  • The support for testing that SwitchYard provides.

Let’s start by looking at the design of the quickstart application and its services.

To import the quickstart into our JBDS workspace, navigate to File→Import→Maven→Existing Maven Projects:

debugger 2

Browse to the quickstarts directory under the directory into which you installed SwitchYard, select the quickstart and it is imported.

debugger 3

The SwitchYard Service Editor

The SwitchYard graphical application editor enables you to create services and references to services, configure gateway bindings for all the protocols that SwitchYard supports, configure message transformers (to convert messages from one format to another), create skeletons of the classes, interfaces, and unit tests for your services.

The service definitions that you create in the editor are stored in a file named switchyard.xml. In the quickstart, this file is located in the src/main/resources/META-INF directory. All the quickstarts that we’ll use in this post follow this same pattern. Let’s open this file in the editor and take a look around.

debugger 4

To open the file in the editor, simple double-click on the switchyard.xml file’s icon. When the editor opens, here’s what we see:

debugger 5

The big blue box in the center window is called the canvas. Here’s where you can see the graphical representation of the service definitions:

debugger 6

At this point, we should take a moment to understand the graphical symbols that are used in the service definitions.

The visual elements defined in switchyard.xml conform to the OASIS Service Component Architecture Assembly Model Specification (http://docs.oasis-open.org/opencsa/sca-assembly/sca-assembly-spec-v1.1.html). The Service Component Architecture (SCA) model provides standards for building SOA applications.

A green chevron represents a service definition. The corresponding purple chevron represents a reference to a service. The blue rectangles are service components. These are containers that can hold implementations or one or more services through references.

Why was this standard selected as the lingua franca of SwitchYard configuration? What advantages does using this standard give us? There are multiple levels of advantages:

  • The SwitchYard team is using a modular approach that makes it easier to define and maintain a service’s configuration. A switchyard.xml can contain binding info in the same file as the service implementation, but SCA also supports recursive composition, so that one service with just implementation details, can be included inside another. We’ll take a look at the SCA files and pictures that Switchyard tooling makes easy to create and maintain.

  • SwitchYard also wanted to make service interface (or the service "contract") information more explicit, and therefore easier to find.

  • Finally, the SwitchYard team had a choice. They could create a new configuration syntax, or they could try to use something that already existed, was an accepted open standard, and was supported by a vibrant community. (They chose the latter.) Also, SCA is a well-known model for service-oriented applications. But, it’s important to not get too hung-up over the underlying configuration model. The capabilities that the model makes possible, such as modularity, are more important. And, another reason to not worry too much about the configuration model is that SwitchYard provides you with tools such as Forge scripting (and someday soon a SCA editor) to make it easier to create and maintain services' configurations.

The set of fundamental service definition symbols is defined in the OASIS Service Component Architecture Assembly Model Specification here: http://docs.oasis-open.org/opencsa/sca-assembly/sca-assembly-1.1-spec-CD-01.html#_Toc193601722

The other symbols relate to the SwitchYard-specific service implementations and bindings. For example, the RoutingService is implemented as a Camel XML service, the DestinationService is implemented as a JBoss Drools service, and the Red, Blue, and Green services are implemented as Java Bean services.

The full range of options supported by SwitchYard is displayed in the Palette view:

debugger 7

(Yes, it’s a long list. You have to scroll to see all the options.)

One thing to keep is that while this service definitions are persisted in an .xml file, and while you are able to view the contents of that file, you should not attempt to edit the raw XML in that file. The editor has built in protections to ensure that you do not create an invalid configuration. These protections are not in effect if you edit the raw XML directly. Accordingly, while we’ll examine both the information available to you in the graphical editor and the switchyard.xml file, we’ll focus on using the editor.

Let’s start by examining the application service design as presented by the editor, in the context of the application logic flow, then we’ll look a bit deeper into how you can create and manage the application design through the editor.

What happens in the quickstart is a three step process:

  • First, the incoming message is routed, by the RoutingService to the DestinationService

  • Second, the DestinationService uses JBossDrools to determine the correct destination for that message, based on the content in the message

  • Third, the RoutingServer then routes the message to the correct final destination (the Red, Green, or Blue service

How is this all accomplished? Let’s look at the RoutingService definition. Select the RoutingService in the diagram, open the Properties view and you’ll see this:

debugger 8

Remember that this service is a Camel XML service. The implementation of that route is defined in the route.xml file. The route definitions take the form of a Spring DSL. (See http://camel.apache.org/spring-xml-extensions.html for more details.)

The contents of this file are pretty self-explanatory as the destination color determines the ultimate destination. For example:

<from uri="switchyard://RoutingService"/>
      <to uri="switchyard://DestinationService"/>
        <choice>
          <when>
              <simple>${body.destination} == 'Red'</simple>
          <to uri="switchyard://RedService"/>

SwitchYard and Routing With Camel (with help from JBoss Drools)

What happens when the quickstart processes a message is:

First, the incoming message is routed, by the RoutingService to the DestinationService.

As seen in route.xml:

    <from uri="switchyard://RoutingService"/>
          <to uri="switchyard://DestinationService”/>

Let’s look at the DestinationService definition. Select the DestinationService in the diagram, open the Properties view and you’ll see this:

debugger 9

Then, the DestinationService service uses an MVEL statement to find the Widget class’s ID, and rules defined in JBoss Drools (remember that this service is implemented as a JBoss Drools service) to set the Destination value:

As seen in DestinationServiceRules.drl:

rule "Red Destination"
          when
              $widget : Widget(id matches "FF0000-.*")
          then
              $widget.getBox().setDestination("Red");
      end

Then, the route logic continues in a structure to route the message to the correct destination:

OK. We have the Destination value set in each widget. But, how does the widget get routed to the correct destination?

Camel provides a Java DSL (Domain Specific Language) to implement routes. In the DSL, a camel route contains a source ("from") and a destination ("to). These reference the RoutingService and DestinationService interfaces that we just saw in the SwitchYard editor.

In the case of the quickstart, the route definitions take the form of a Spring DSL. The route is self-explanatory, even if you do not have experience with Camel. The destination service is selected based on the content; Red, Green, or Blue.

Test Support in SwitchYard

There’s just one more thing we have to look at before we run the quickstart - how to start the chain reaction of tasks that the quickstart will perform.

Testing server-side applications such as those built with SwitchYard can be difficult. Since this is server-side software, you have to install and run a server, the application has to be deployed to that server, and then you have to construct a client to access the application on the server. You can end up in a situation where you have to build either a throwaway test client, or a reusable test framework. Either way, you have to invest time and effort into building something other than your application.

Luckily, JBoss SwitchYard provides a built in framework that makes testing your applications fast and easy. This QuickStart makes use of the SwitchYardRunner class. SwitchYardRunner is a JUnit Runner class, but more than that, it starts up an embedded SwitchYard runtime. When this embedded runtime starts, your application is packaged up as a SwitchYard application that is deployed to the test instance.

To make use of SwitchYard’s test support, all you have to do is to annotate the test with the SwitchYardRunner JUnit test Runner class. This class will startup an embedded SwitchYard runtime, one for each test method, and then package up the test into a SwitchYard application and deploy that application to the runtime.

In addition to the SwitchYardRunner class, SwitchYard also makes testing easy by providing the TestMixIn feature. TestMixIns enable to turn on additional test support, based on the specific needs of your application. This quickstart makes use of the CDIMixIn to register its bean services. Some of the other TestMixIns support testing http services, JBoss Smooks transformations, and JMS services.

Building, Deploying, and Running the Quickstart

OK, enough talk. Let’s run the quickstart.

First, deploy the quickstart to a SwitchYard server. In JBDS, this is a simple task. It can be done with the server either started or stopped, but let’s start the server first so that you more easily spot the server logging messages when the quickstart is deployed.

To start the server, select it in the “servers” view, and press the start button.

debugger 10

The server console window will open, and you should see something like this:

21:21:59,145 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://127.0.0.1:9990/management
      21:21:59,146 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:9990
      21:21:59,146 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015874: WildFly 8.0.0.Final "WildFly" started in 4060ms

Then, to deploy the quickstart, select the server in the “servers” view again, right-click, select “Add/Remove Applications” and select the quickstart.

debugger 11

Switch back to the console view and you should see something like this:

INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS018559: Deployed "switchyard-quickstart-rules-camel-cbr.jar" (runtime-name : "switchyard-quickstart-rules-camel-cbr.jar")

To run the client test program, select the rules-camel-cbr/src/test/java/org/switchyard/quickstarts/rules/camel/cbr/RulesCamelCBRTest.java Java source file, and run it as a JUnit test.

Switch back to the server console, and you’ll see the quick start’s output!

INFO  [org.switchyard.quickstarts.rules.camel.cbr.RedServiceBean] Red service processing boxed widget with id: FF0000-ABC-123
      INFO  [org.switchyard.quickstarts.rules.camel.cbr.GreenServiceBean] Green service processing boxed widget with id: 00FF00-DEF-456
      INFO  [org.switchyard.quickstarts.rules.camel.cbr.BlueServiceBean] Blue service processing boxed widget with id: 0000FF-GHI-789

And the green bar appears!

debugger 12

Now, we’ll use the debugger to interrupt a running service in a QuickStart and enable us to examine the data in a message being processed by the service. After this, we’ll take things one step further and introduce a bug into a service and then use the debugger to find that bug.

Setting a Breakpoint in the Debugger

Let’s start by setting a breakpoint on the Blue service. We’ll use this breakpoint to enable us to view the contents of the message received by the service. For the purposes of our first example, we’ll use the Blue service.

To set a breakpoint in the SwitchYard editor, first position the cursor over the service’s green chevron icon. A small palette of icons is displayed:

debugger 13

To set a breakpoint on the service, select the eyeglasses icon. The presence of this icon on a service definition as seen in the SwitchYard editor indicates that a breakpoint is set:

debugger 14

Notes that as we are adding a breakpoint on the service, the breakpoint will trigger for any reference or composite service invoking that service. In contrast, if you add a breakpoint on a service reference, it will only break when that reference is invoked.

To view and modify the breakpoint’s properties, open the Debug perspective and look in the breakpoints view:

debugger 15

And then right-click on the breakpoint, to view and edit the breakpoint’s properties:

debugger 16

For our example, we’ll use the default properties. We’re mainly concerned with the breakpoint being triggered at service entry.

Now that our breakpoint has been defined, let’s run the RulesCamelCBRTest program again.

To run the test with the debugger, right-click on RulesCamelCBRTest, select Debug As→JUnit Test:

debugger 17

When the breakpoint is reached, the program is suspended. If we look in the Variables view in the Debug perspective, we can see the incoming message and the values that controlled the content-based routing of a message to the Blue service:

debugger 18

Now that we’ve seen the quickstart run correctly, it’s time to introduce a bug, and then use the debugger to find it. For this illustration, we’ll use a different quickstart.

Giving a Quickstart a Bug

Remember the scene in the movie “Independence Day,” when Will Smith uploads a software virus into the evil aliens’ spaceship? Let’s do something similar and add a bug into a quickstart, and then use the debugger to find the bug and even fix it.

Some of the types of bugs that you have to deal with in a services and message based system involve when there are problems in the content in the messages, and how the services are (or are not) able to handle those problems. What sorts of bad things can happen to good messages? Missing a field, wrong namespace, malformed XML, errors in the headers, etc. The debugger makes it possible to tweak a message to debug a problem, without having to redeploy the service.

The quickstart that we’ll look at is “validate-xml.” This quickstart demonstrates the SwitchYard XML validator. The quickstart deploys a service that accepts a message and returns an object that is transformed with XLST. The incoming message is checked for XML validity, so that malformed messages are caught. Before we can run the quickstart, it must be deployed in the same manner as the rules-camel-cbr quickstart that we looked at earlier in this article.

The quickstart’s application diagram is very simple as only one service (“OrderService”) is implemented. This service only accepts a message and returns an object that is processed by the XLST transformer, but it’s adequate for our purposes. The diagram looks like this:

debugger 19

The test application that we want to run is: validate-xml/src/test/java/org/switchyard/quickstarts/validate/xml/WebServiceTest.java

This application executes separate two Junit tests. First, it verifies that a properly formatted SOAP message can be transformed and validated, and then it verifies that an intentionally malformed SOAP message (that is, a message that contains invalid XML) is caught.

Before we look at causing and catching a bug, let’s examine the message tansformation that is performed by this quickstart. The transformation is performed with the order.xslt file in the quickstart. It’s a simple transformation in that it transforms incoming messages that look like this:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
        <soapenv:Header/>
        <soapenv:Body>
        <orders:order xmlns:orders="urn:switchyard-quickstart:validate-xml:0.1.0">
           <orderId>PO-19838-XYZ</orderId>
           <itemId>BUTTER</itemId>
           <quantity>200</quantity>
        </orders:order>
        </soapenv:Body>
      </soapenv:Envelope>

Into objects that look like this:

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
        <SOAP-ENV:Header/>
        <SOAP-ENV:Body>
        <orders:orderAck xmlns:orders="urn:switchyard-quickstart:validate-xml:0.1.0">
           <orderId>PO-19838-XYZ</orderId>
           <accepted>true</accepted>
           <status>Order Accepted</status>
        </orders:orderAck>
        </SOAP-ENV:Body>
      </SOAP-ENV:Envelope>

The change simply indicates whether the incoming order was accepted.

If we set our breakpoint on the “OrderService” service:

debugger 20

And then run/debug the WebServiceTest, we can view the message, before and after its transformation, in the debugger. Here’s the message before transformation:

debugger 21

And here’s the message after its transformation:

debugger 22

The second test in the WebServiceTest intentionally sends a message that includes an invalid XML element.

The invalid SOAP message looks like this:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
        <soapenv:Header/>
        <soapenv:Body>
        <orders:order xmlns:orders="urn:switchyard-quickstart:validate-xml:0.1.0">
           <orderId>PO-19838-XYZ</orderId>
           <itemId>BUTTER</itemId>
           <quantity>200</quantity>
           <invalid-element>This element is not allowed by XML Schema.</invalid-element>
        </orders:order>
        </soapenv:Body>
      </soapenv:Envelope>

Yes, it’s easy to spot the invalid XML. ;-)

Let’s expand on this test application a bit and alter it to not gracefully trap the error resulting from the invalid XML. To do this, we’ll edit the invokeOrderWebServiceValidationFail() method and change this:

Assert.assertTrue("Unexpected response: " + response, response.contains("1 validation error(s)") && response.contains("invalid-element"));

To this:

Assert.assertFalse("Unexpected response: " + response, response.contains("1 validation error(s)") && response.contains("invalid-element"));

So that when we run the test, we see this JUnit error:

java.lang.AssertionError: Unexpected response: <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><soap:Fault><faultcode>soap:Server</faultcode><faultstring>SWITCHYARD014000: Validator 'org.switchyard.validate.xml.internal.XmlValidator' failed: 1 validation error(s):
      org.xml.sax.SAXParseException: cvc-complex-type.2.4.d: Invalid content was found starting with element 'invalid-element'. No child element is expected at this point.
      </faultstring></soap:Fault></soap:Body></soap:Envelope>

Before we can debug the OrderService, we must set our breakpoint:

debugger 23

Then we edit the breakpoint’s properties. For our example, we want the trigger to be set for the validation of incoming messages:

debugger 24

When we run/debug the WebServiceTest program, the breakpoint is reached and we can examine the message contents:

debugger 25

And, there’s the invalid XML element. What makes the debugger especially useful is that we can now edit the message and remove the invalid XML:

debugger 26

And then allow the program to resume its operation. In this way, we can determine if the program has any other bugs before we correct the cause of the invalid XML, redeploy, etc.

In Conclusion

We’ve taken an introductory look at the new SwitchYard debugger in this article. The debugger enables you to debug not just a class or method, but a Switchyard service. The debugger is configured through the SwitchYard graphical service/application editor and enables you to both monitor and control the operation of a service to make it easier for you to find those pesky bugs and is a great addition to the SwitchYard developer toolkit.

Acknowledgements

The author would like to thank Rob Cernich for his input and reviews of the article as it was being written, Keith Babo for his background on the SwitchYard editor, and Jiri Sedlacek for his painstaking review of my sometimes suspect grammar. (Many thanks!)

References


by ldimaggio at November 27, 2014 03:11 PM

Early access to Luna capable integration tools.

by pleacu at November 27, 2014 03:11 PM

JBoss Tools Integration Stack 4.2.0.Beta1 / JBoss Developer Studio Integration Stack 8.0.0.Beta1

jbosstools jbdevstudio blog header

The Integration Stack for JBoss Tools Developer Studio is a set of plugins for Eclipse that provides tooling for the following frameworks.

JBoss Business Process and Rules Development

  • BPEL Designer - Orchestrating your business processes.

  • BPMN2 Modeler - A graphical modeling tool which allows creation and editing of Business Process Modeling Notation diagrams using graphiti.

  • Drools - A Business Logic integration Platform which provides a unified and integrated platform for Rules, Workflow and Event Processing.

  • jBPM - A flexible Business Process Management (BPM) suite.

JBoss Data Virtualization Development

  • Modeshape - A distributed, hierarchical, transactional and consistent data store with support for queries, full-text search, events, versioning, references, and flexible and dynamic schemas. It is very fast, highly available, extremely scalable, and it is 100% open source.

  • Teiid Designer - A visual tool that enables rapid, model-driven definition, integration, management and testing of data services without programming using the Teiid runtime framework.

JBoss Integration and SOA Development

  • All of the Business Process and Rules Development plugins, plus…​

  • Fuse Apache Camel Tooling - A graphical tool for integrating software components that works with Apache ServiceMix, Apache ActiveMQ, Apache Camel and the FuseSource distributions.

  • SwitchYard - A lightweight service delivery framework providing full lifecycle support for developing, deploying, and managing service-oriented applications.

SOA 5.x Development

  • JBoss ESB - An enterprise service bus for connecting enterprise applications and services.

  • jBPM3 - A flexible Business Process Management (BPM) Suite - JBoss Enterprise SOA Platform 5.3.x compatible version.

All of these components have been verified to work with the same dependencies as JBoss Tools 4.2 and Developer Studio 8.

Installation

To install the Integration Stack tools, first install JBoss Developer Studio from the all-in-one installer, bundled and configured out of the box with everything you need to get started. Alternatively, if you already have eclipse-jee-luna installed, you can install JBoss Developer Studio or JBoss Tools from the Eclipse Marketplace via Help > Eclipse Marketplace…​

jbtis-luna-em

Once Developer Studio is installed, restart Eclipse and select the Software/Update tab in the JBoss Central view. The current 8.0.0.Beta1 integration stack is available as "Early Access" so you must check the "Enable Early Access" checkbox in the installer window. Select the items you’d like to install:

jbdsis-ea

The standard p2 installer is available for JBDSIS. Simply start jbdevstudio or eclipse-with-jbds, then:

       Help > Install New Software...
             Add...
             - use this for 'Location:'
               https://devstudio.redhat.com/updates/8.0-development/integration-stack/

The community JBoss Tools Integration Stack (JBTIS) installation is easy as well. If you already have eclipse-jee-luna installed, install JBoss Tools from the Eclipse Marketplace via Help > Eclipse Marketplace…​

jbtis-luna-em

Once JBoss Tools is installed, restart Eclipse and select the Software/Update tab in the JBoss Central view. The current 4.2.0.Beta1 integration stack is available as "Early Access" so you must check the "Enable Early Access" checkbox in the installer window. Select the items you’d like to install:

jbtis-ea

The standard p2 installer is available for JBTIS. Simply start eclipse-with-jbt, then:

       Help > Install New Software...
             Add...
             - use this for 'Location:'
               http://download.jboss.org/jbosstools/updates/development/luna/integration-stack/

Note: If you installed into your own Eclipse you should bump up the launch resource parameters:

--launcher.XXMaxPermSize 256m --launcher.appendVmargs -vmargs -Dosgi.requiredJavaVersion=1.6 -XX:MaxPermSize=256m -Xms512m -Xmx1024m

What’s Been Updated?

This is a Beta1 release so some things are in flux but virtually every component has something new or updated. Here’s a small list of what’s new:

Fuse Tooling

  • Improved server adapters for JBoss Fuse Tooling. More logical deployment and publishing of your projects from the Servers view.

  • There’s new Camel route debug support in the Fuse Camel route editor.

See Lars Heinemann’s Blog for more insights.

Teiid Designer

Three releases for Teiid Designer, see Teiid Designer 8.4, Teiid Designer 8.5 and Teiid Designer 8.6 What’s New.

Keep up to date with the JBoss Tools home

Don’t miss the Features tab for up to date information on your favorite Integration Stack component!


by pleacu at November 27, 2014 03:11 PM

JBoss Tools Integration Stack 4.1.6.Final / JBoss Developer Studio Integration Stack 7.0.3.GA

by pleacu at November 27, 2014 03:11 PM

Maintenance update of your favorite integration tools.

jbosstools jbdevstudio blog header

The Integration Stack for JBoss Tools Developer Studio is a set of plugins for Eclipse that provides tooling for the following frameworks:

  • BPEL Designer - Orchestrating your business processes.

  • BPMN2 Modeler - A graphical modeling tool which allows creation and editing of Business Process Modeling Notation diagrams using graphiti.

  • Drools - A Business Logic integration Platform which provides a unified and integrated platform for Rules, Workflow and Event Processing.

  • JBoss ESB - An enterprise service bus for connecting enterprise applications and services.

  • Fuse Apache Camel Tooling - A graphical tool for integrating software components that works with Apache ServiceMix, Apache ActiveMQ, Apache Camel and the FuseSource distributions.

  • jBPM3 - A flexible Business Process Management (BPM) Suite - JBoss Enterprise SOA Platform 5.3.x compatible version.

  • Modeshape - A distributed, hierarchical, transactional and consistent data store with support for queries, full-text search, events, versioning, references, and flexible and dynamic schemas. It is very fast, highly available, extremely scalable, and it is 100% open source.

  • SwitchYard - A lightweight service delivery framework providing full lifecycle support for developing, deploying, and managing service-oriented applications.

  • Teiid Designer - A visual tool that enables rapid, model-driven definition, integration, management and testing of data services without programming using the Teiid runtime framework.

All of these components have been verified to work with the same dependencies as JBoss Tools 4.1 and Developer Studio 7, so installation is easy.

Installation

To install the Integration Stack tools, first install JBoss Developer Studio from the all-in-one installer, bundled and configured out of the box with everything you need to get started. Alternatively, if you already have eclipse-jee-kepler installed, you can install JBoss Developer Studio or JBoss Tools from the Eclipse Marketplace via Help > Eclipse Marketplace…​

jbtis-b1

Once Developer Studio is installed, restart Eclipse and select the Software/Update tab in the JBoss Central view and look for the JBoss Developer Studio Integration Stack installation section. Select the items you’d like to install:

jbtis-b2

The community JBoss Tools Integration Stack URL is:

Note: If you installed into your own Eclipse you should bump up the launch resource parameters:

--launcher.XXMaxPermSize 256m --launcher.appendVmargs -vmargs -Dosgi.requiredJavaVersion=1.6 -XX:MaxPermSize=256m -Xms512m -Xmx1024m

What’s Been Updated?

Fix release versions of Fuse Tooling 7.2.2, jBPM/Drools 6.1.0 and Teiid Designer 8.3.4. Also - there are updated ESB 1.5.310.Final project examples. Look for specific bug fixes in the Release Notes.

Keep up to date with the JBoss Tools home

Don’t miss the new Features tab for up to date information on your favorite Integration Stack component !


by pleacu at November 27, 2014 03:11 PM

Eclipse Newsletter - Looking Towards Mars

November 26, 2014 05:09 PM

Read the lastest Eclipse Newsletter and check out the new theme!

November 26, 2014 05:09 PM

SWT Mouse Click Implementation

by Frank Appel at November 26, 2014 12:14 PM

Written by Frank Appel

Doing a bit of SWT custom widget development lately, I stumbled across the question why is there no such thing as a default SWT mouse click listener? As this subject raises once in a while, I thought writing a word or two about the rational ground behind – and how to implement mouse clicks in general – would not hurt.

SWT Mouse Click

Event driven widget toolkits usually distinguish between low-level and semantic events. A low-level event represents window system occurrences or low level input. The mouse and keyboard inputs belong basically to this group.

Semantic events in turn are the result of control specific user interaction and might be composed of one or more low-level events. A button-click for example could be specified as a mouse-down followed by a mouse-up without the mouse leaving the bounds of the control.

The point of the matter is the control specific user interaction. An image-click might be specified as a mouse-down followed by a mouse-up without leaving the bounds of particular regions of the image. Which makes a small but mighty difference.

The semantic event type SWT.Selection e.g. corresponds to the button-click specification given above for the org.eclipse.swt.widgets.Button control. But its composition is quite different on org.eclipse.swt.widgets.Slider. The latter behaves rather like the image-click definition:

SWT Mouse Click: Mouse Click on Slider

It is obvious that nobody would like to add particular listeners for mouse-click events on each of the control’s regions. It is much more comfortable to have a semantic abstraction based on those low-level events that notifies observers about the crucial point or interest1.

Button Click for Custom Widgets

So how can a button-click event implementation look like on a (sub-)component of a custom SWT widget? Consider for example a Composite comprised of a few labels and one of those – for whatever reason – should serve as an action trigger.

The click behavior could be accomplished with a little action wrapper working on top of the typed event abstraction of SWT. It may implement/extend org.eclipse.swt.events.MouseListener/-MouseAdapter and can be registered at controls to serve as a button-click listener:

class ClickBehavior extends MouseAdapter {

  private final Runnable action;

  ClickBehavior( Runnable action ) {
    this.action = action;
  }

  @Override
  public void mouseDown( MouseEvent event ) {
    // TODO: decent implementation
  }

  @Override
  public void mouseUp( MouseEvent event ) {
    // TODO: decent implementation
  }
}

As you can see the class ClickBehavior wraps a Runnable which should be triggered by a click on the observed control. To do so the first step is to verify that a left-mouse-button-down has occured and flag the observer to be trigger ready. A simple mouseDown implementation might look like this:

public static final int LEFT_BUTTON = 1;
[...]
public void mouseDown( MouseEvent event ) {
  if( event.button == LEFT_BUTTON ) {
    armed = true;
  }
}

The second step is to check whether a subsequent mouseUp event has occured within the bounds of the monitored control. If so (and armed) the semantic condition has been fulfilled and the action can be triggered2:

public void mouseUp( MouseEvent event ) {
  if( armed && inRange( event ) ) {
    action.run();
  }
  armed = false;
}

static boolean inRange( MouseEvent event ) {
  Point size
    = ( ( Control )event.widget ).getSize();
  return    event.x >= 0 
         && event.x <= size.x
         && event.y >= 0
         && event.y <= size.y;
}

This implementation is sufficient to be able to handle a 'button-click' event on e.g. a org.eclipse.widgets.Label as shown by the following snippet:

final Shell shell = [...];
Label label = new Label( shell, SWT.NONE );
label.setText( "Click me!" );
label.addMouseListener(
  new ClickBehavior( new Runnable() {

  @Override
  public void run() {
    MessageBox box = new MessageBox( shell );
    box.setMessage( "Label was clicked." );
    box.setText( "Message" );
    box.open();
  }

} ) );

And voilà, this is how it looks like at runtime:

SWT Mouse Click: Label Click

Wrap Up

As explained above there are good reasons for SWT to omit a general purpose mouse click implementation. And the given example showed how to implement a simple button-click semantic for custom widgets. However there is still more to consider. Widgets often react on mouse down visually to indicate that they are trigger-ready for example.

Because of this custom widget code gets quickly blown up and tend to blur the various event related reponsibilities. For a clean separation of the event-semantic from the visual-effect code, I usually extract the first one in a little helper class. I even have a general purpose version for button-click events called ButtonClick, which is part of the SWT utility feature of the Xiliary P2 repository.

In case all this mouse click related content raised a desire for some practical application of mouse clicking: how about using the social buttons below to share the knowledge? ;-)

Title Image: © Depositphotos.com/HoldenKolf

  1. The attentive reader may have recognized that I omit the slider's drag region which also adds to the selection semantic. This is because it does not match the click behaviour and would go beyond the scope of this discussion.
  2. It might be noteworthy to mention that a real world implementation should ensure that the armed flag gets also reset in case a runtime exception is thrown during action.run().

The post SWT Mouse Click Implementation appeared first on Code Affine.


by Frank Appel at November 26, 2014 12:14 PM

Jigsaw, modules and OSGI - next round

by Andrey Loskutov at November 26, 2014 08:23 AM

 Jigsaw project goes to the next round [1] with the new "Java Platform Module System" JSR 376...

At least OSGI is mentioned this time, quote:

"Some members of the Java community have already invested significantly in applications and frameworks built on top of the OSGi Service Platform."

Buhaha. "Some members"! The whole world except Oracle is using OSGI today... I'm pretty sure Oracle does this too...

" The module system will provide a means for an OSGi kernel to locate Java modules and resolve them using its own resolver, except possibly for core system modules. This will enable OSGi bundles running in such a kernel to depend upon Java modules."

Have no idea how OSGI bundles should depend upon new modules if "module" is not defined in OSGI at all, OSGI defines "bundles". So the new modules will be offered as "faked" bundles to OSGI? NIH principle at glance.

Just wondering - there is not a single word about version schema and version constraints... If this will be different to OSGI, we will have even more fun later...

[1] https://jcp.org/en/jsr/detail?id=376


by Andrey Loskutov at November 26, 2014 08:23 AM

TextEditor Framework with e4 and JavaFX (including jdt and nashorn)

by Tom Schindl at November 26, 2014 12:25 AM

Tonight I had some time to hack on a research project which uses the StyledTextControl provided by e(fx)clipse. Syntax highlighting for the basic languages like Java, JavaScript, XML and groovy has already been implemented since a long time.

So next on my list was support for outlines which turned out to be fairly easy. Watch the video to see it in action.

If you watched the video you noticed that while a generic outline for Java makes always sense for JavaScript it does not necessarily because frameworks invented their own way to define a class. In my example I used qooxdoo – because I knew it from earlier work – but the same applies for others as well.

Java

For Java I simply added org.eclipse.jdt.core and the main logic then looks like this:

	@Override
	public Outline createOutline(Input<?> input) {
		ASTParser parser = ASTParser.newParser(AST.JLS8);
		parser.setKind(ASTParser.K_COMPILATION_UNIT);
	    parser.setSource(input.getData().toString().toCharArray());
	    parser.setResolveBindings(true);
	    ASTNode cu = parser.createAST(null);

	    Stack<OutlineItem> i = new Stack<>();
        i.push(new JavaOutlineItem("<root>",null));

	    cu.accept(new ASTVisitor() {

	    	@Override
	    	public boolean visit(TypeDeclaration node) {
	    		OutlineItem o = new JavaOutlineItem(node.getName().getFullyQualifiedName(), "java-class");
	    		i.peek().getChildren().add(o);
	    		i.push(o);

	    		return super.visit(node);
	    	}

	    	@Override
	    	public void endVisit(TypeDeclaration node) {
	    		i.pop();
	    		super.endVisit(node);
	    	}

	    	@Override
	    	public boolean visit(FieldDeclaration node) {
	    		for( Object v : node.fragments() ) {
	    			if( v instanceof VariableDeclarationFragment ) {
	    				VariableDeclarationFragment vdf = (VariableDeclarationFragment) v;
	    				i.peek().getChildren().add(new JavaOutlineItem(vdf.getName().getFullyQualifiedName(), "java-field"));
	    			}
	    		}
	    		return super.visit(node);
	    	}

	    	@Override
	    	public boolean visit(MethodDeclaration node) {
	    		i.peek().getChildren().add(new JavaOutlineItem(node.getName().getFullyQualifiedName(), "java-method"));
	    		return super.visit(node);
	    	}

		});
		return new JavaOutline(i.peek());
	}

JavaScript

We only look at the enhanced outline contributed to the framework. To understand it better here’s some simple background:

  1. A class definition is done with qx.Class.define
  2. Properties are defined in the properties-Attribute
  3. Members are defined in the members-Attribute
  4. Names with _ means protected, __ means private

So I used Nashorn to parse the JavaScript files like this:

@Override
  public Outline createOutline(Input<?> input) {
    final Options options = new Options("nashorn");
    options.set("anon.functions", true);
    options.set("parse.only", true);
    options.set("scripting", true);

    ErrorManager errors = new ErrorManager();
    Context context = new Context(options, errors, Thread.currentThread().getContextClassLoader());

    Context.setGlobal(new Global( context ));

    final Source   source   = Source.sourceFor("dummy.js", input.getData().toString().toCharArray());
    FunctionNode node = new Parser(context.getEnv(), source, errors).parse();

    JSOutlineItem root = new JSOutlineItem("<root>",null);

    node.accept(new NodeVisitor<LexicalContext>(new LexicalContext()) {
			private JSOutlineItem classDef;

			@Override
			public boolean enterCallNode(CallNode callNode) {
				if( callNode.getFunction().toString().endsWith("qx.Class.define") ) {
					classDef = new JSOutlineItem(((LiteralNode<?>)callNode.getArgs().get(0)).getString(), "qx-class-def");
					root.getChildren().add(classDef);
				}
				return super.enterCallNode(callNode);
			}

			@Override
			public boolean enterPropertyNode(PropertyNode propertyNode) {
				if( classDef != null ) {
					switch (propertyNode.getKeyName()) {
					case "include":
						break;
					case "extend":
						break;
					case "construct":
						break;
					case "statics":
						break;
					case "events":
						break;
					case "properties":
						classDef.getChildren().add(handleProperties(propertyNode));
						break;
					case "members":
						classDef.getChildren().add(handleMembers(propertyNode));
						break;
					default:
						break;
					}
				}
				return super.enterPropertyNode(propertyNode);
			}
		});
		return new JSOutline(root);
	}

	private JSOutlineItem handleProperties(PropertyNode p) {
		JSOutlineItem outline = new JSOutlineItem("Properties", "qx-properties");
		p.accept(new NodeVisitor<LexicalContext>(new LexicalContext()) {
			@Override
			public boolean enterPropertyNode(PropertyNode propertyNode) {
				if( p != propertyNode ) {
					outline.getChildren().add(new JSOutlineItem(propertyNode.getKeyName(), "qx-property-"+visibility(propertyNode.getKeyName())));
					return false;
				}

				return true;
			}
		});
		return outline;
	}

	private JSOutlineItem handleMembers(PropertyNode p) {
		JSOutlineItem outline = new JSOutlineItem("Members", "qx-members");
		p.accept(new NodeVisitor<LexicalContext>(new LexicalContext()) {
			@Override
			public boolean enterPropertyNode(PropertyNode propertyNode) {
				if( p != propertyNode ) {
					if( propertyNode.getValue() instanceof FunctionNode ) {
						outline.getChildren().add(new JSOutlineItem(propertyNode.getKeyName()+"()","qx-method-"+visibility(propertyNode.getKeyName())));
					} else if( propertyNode.getValue() instanceof ObjectNode ) {
						outline.getChildren().add(new JSOutlineItem(propertyNode.getKeyName(),"qx-field-"+visibility(propertyNode.getKeyName())));
					} else if( propertyNode.getValue() instanceof LiteralNode<?> ) {
						outline.getChildren().add(new JSOutlineItem(propertyNode.getKeyName(),"qx-field-"+visibility(propertyNode.getKeyName())));
					} else {
						System.err.println("Unknown value type: " + propertyNode.getValue().getClass());
					}
					return false;
				}
				return true;
			}
		});
		return outline;
	}

	private static String visibility(String name) {
		if( name.startsWith("__") ) {
			return "private";
		} else if( name.startsWith("_") ) {
			return "protected";
		}
		return "public";
	}

Next on my list are improvements for the editor-control which still lacks some features and afterwards I want:

  1. Syntax hightlighting for C/C++
  2. Syntax hightlighting for TypeScript
  3. Syntax hightlighting for Swift
  4. Error and warnings for Java, JavaScipt and TypeScript
  5. Auto-Complete for Java


by Tom Schindl at November 26, 2014 12:25 AM

Building Plugin through Jenkins- CI

by Its_Me_Malai (noreply@blogger.com) at November 25, 2014 01:41 PM

Building Plugin through Jenkins- CI 


Having learnt how to build a HelloWorld Plugin using Maven Tycho from Eclipse, the next step is to learn to Automate the Build thru Continous Build Integration System Jenkins.

Step 1. Install Jenkins. It is a war file. Download the same from http://jenkins-ci.org/

Step 2. Deploy the same in tomcat or any Java Container App Server that you have installed by copying into the relevant folder. For tomcat you need to copy it into the webapps folder.

Step 3. Start your Server and on your browser connect to http://localhost:8080/jenkins


It should open a browser content as shown above.

Step 4. Click on Manage Jenkins in the left hand side menu.

Step 5. Click on Configure System > Maven > Add Maven Installer and Select Required Version.

Step 6. Click on Jenkins on top left corner > Create a New Job

Step 7. Provide Job Name


Step 8. Select Build a Maven2/3 Project and Finish

Step 9. Project Configuration Page would open. Scroll down to find Pre Step section


Step 10. Configure the parent pom.xml location and commands that you want to run thru mvn.

Step 11. Save and Apply the Changes. Click on Build Now.

Step 12. Click on the Build Link > Console Output to visualise the Build in Progress.

Step 13. Build should be Successful > Target folder of the Project would contain your plugin.jar.

by Its_Me_Malai (noreply@blogger.com) at November 25, 2014 01:41 PM

Project Flux: Connecting developer tools across desktop and web

by Eclipse Foundation at November 25, 2014 12:31 PM

In recent years there has been a steady migration of tools to the web, starting with bug trackers and other collaboration tools. More recently core coding tools have started moving to the web as well, with the rise of web code editors such as Eclipse Orion. However when developers make this leap to web-based tools, they must leave behind their existing tools because there is no way to for tools on the web to connect back to tools on the desktop. This talk introduces Flux, a new project that aims at bridging this gap between existing desktop-class IDEs and future cloud-based developer tooling. It is built around a new cloud-based architecture for developer tooling that integrates with todays desktop IDEs (like Eclipse, IntelliJ, or even Sublime Text). This new architecture takes existing IDEs explicitly into account, but allows developers to move towards cloud- and browser-based tooling at the same time. It provides, for example, real Java reconciling and compilation information, content-assist and navigation support in the browser, in real-time, without forcing developers to discard their desktop IDEs. The talk explains the architecture behind this new project and shows several live demos using the latest prototypes, the integration with Eclipse Orion, Java tooling in the cloud, and more. Here is the online version of the slides: http://jarthorn.github.io/JavaOne2014/flux/index.html#/

by Eclipse Foundation at November 25, 2014 12:31 PM

Building a Feature using Maven Tycho

by Its_Me_Malai (noreply@blogger.com) at November 25, 2014 12:10 PM

Building a Feature using Maven Tycho

Step 1. Create a Feature Project with required functionality.

Step 2. Convert the Feature Project to Maven Project

a. Right Click on the Plugin Project > Select Configure > Convert to Maven Project



Step 3. Wizard to create pom.xml would Open. Configure the same as mentioned below

a. Change the version from 0.0.1-SNAPSHOT to 1.0.0-SNAPSHOT

b. Change Packaging from jar to eclipse-feature. This option is not available in the dropdown.



Step 4. Pom.xml on creation would look as shown below



a. I am sure you know why we are seeing an error. Tycho-maven-plugin is missing in the feature’s 

pom.xml. You can remove the error by adding the required plugin to the pom or the 

recommended solution is tycho-maven-plugin is being shared by Feature and Plugin Project 

pom.xml, therefore we add it to the parent pom.xml


Step 5. To fix these errors follow the steps below

a. We need to add a Maven Plugin called tycho-maven-plugin to parent pom.xml

b. Right Click on the parent pom.xml > Select Maven > Add Plugin



Step 6. In the Add Plugin Dialog, type tycho in the textBox as shown below

a. Select org.eclipse.tycho tycho-maven-plugin



b. Open the pom.xml and we need to manually alter the pom.xml to have a new tag called as 

true after versions in the plugin tag. Errors from the pom.xml file 

should be all resolved now.


Step 7. Adding Repository for dependancies resolution

a. Repositories are also shared between the Plugin Project and Feature Project. Therefore the 

same is also moved to the parent POM.

Step 8. Add the Feature Project as a module to the parent pom.xml.

Step 9. Right Click on Feature Project and Select Maven > Update Project to fix the Errors on feature proj

Step 10. Now select the pom.xml and right on the same to run > maven install



Step 11. On Successful build > the Target folder would be updated as shown below


References to read

1. http://codeandme.blogspot.in/2012/12/tycho-build-1-building-plug-ins.html

2. http://www.vogella.com/articles/EclipseTycho/article.html

by Its_Me_Malai (noreply@blogger.com) at November 25, 2014 12:10 PM

Many Bundles of Things

by Eclipse Foundation at November 25, 2014 11:53 AM

This presentation tells how OSGi can help developing a distributed and cloud ready Internet of Things platform. IoT brings unprecedented complexity both in terms of technological variety and new development paradigms. Modularity offered by OSGi is the key concept to build maintainable and robust IoT platforms. OSGi declarative services and dependency injection mechanism allow service producers and service consumers to interact with full respect of mutual component boundaries: this is the fundamental requirement to enable important aspects of an IoT platform like multi-tenancy, separation of concerns between M2M protocols management and application development and dynamic services management. Plat.One IoT platform revolves around the OSGi technology: this presentation describes our lesson learnt during several years of “hands-on OSGi activities” and development.

by Eclipse Foundation at November 25, 2014 11:53 AM

Scaling and Orchestrating Microservices with OSGi

by Eclipse Foundation at November 25, 2014 11:52 AM

The OSGi community has been designing and developing microservices since 1998, and we have gained a great deal of experience with them. The isolation provided by OSGi's Module Layer provides a high degree of safety, along with a powerful model for versioning API contracts and filtering out incompatible service providers. However, OSGi bundles exist within the memory space of a process, and so make a trade-off in favour of simplicity and speed. We are not protected from crashes originating in other modules -- when such protection is required, we can use separate OS processes. This mirrors the general industry trend of developing "microservices". But in return for additional safety we create complexity; not least in the number of artifacts and processes that must be managed. Still, even processes do not provide perfect isolation, and increasingly container models such as Docker are being used to control resource utilisation. Above this, full VMs are used to provide different OS environment to different services. So we see that isolation and modularity are a continuum of trade-offs, and OSGi bundles exist towards the lower end of it. But getting application modularity right is extremely important to avoid much greater complexity at the higher ends. In this talk I will describe how OSGi works as a key part of the modern application architecture and DevOps stack, highlighting the OSGi technologies that can be used to scale upwards and outwards. The talk will include a significant demo section.

by Eclipse Foundation at November 25, 2014 11:52 AM

openHAB 1.6 and 2.0 alpha Release

by Kai Kreuzer (noreply@blogger.com) at November 24, 2014 07:34 PM

We have reached another milestone – openHAB 1.6 has been released! As usual, it brings a couple of new bindings and other add-ons. Just to name a few: There is now support for Belkin WeMo switches, LG TVs, BenQ beamers and Samsung air conditioners. A very interesting new system-to-system integration is now possible with MiOS-bases systems, such as the MiCasaVerde (now Vera Control). But with this release it seems that the focus of development has shifted slightly: While we had huge numbers of new bindings with every release in the past, we “only” have 17 new add-ons this time. But this does not at all mean that there is any slow down in the project activity; the opposite is the case: The community is growing massively and as a result we see more and more people improving existing add-ons and introducing new features to them – the very lively Z-Wave binding that is led by Chris Jacksonis the best example for this.

The community growth is nicely visualized in the OpenHUB (formerly Ohloh) statistics:


The factoids state: “Over the past twelve months, 147 developers contributed new code to openHAB. This is one of the largest open-source teams in the world, and is in the top 2% of all project teams on Open Hub.” - we can be really proud of this community!

openHAB 2.0 alpha


Despite the large number of code commits in 1.6, there has not been much evolution on the core runtime itself. There is a very simple reason for this: The work on openHAB 2!

As a recap: One year ago we contributed the core parts of openHAB to the Eclipse Foundation to start off the Eclipse SmartHome project. This project provides a framework for building smart home solutions – and openHAB 2 will be one of such solutions. Others, like e.g. Deutsche Telekom with its QIVICONplatform and Yetu also chose Eclipse SmartHome as a part of the software stack for their home gateways.

Being a general purpose framework for smart home gateways implies that Eclipse SmartHome has its emphasis on providing means to build user-friendly configuration interfaces as well as optimizing it for embedded systems – both topics were not in focus for openHAB 1.

To show where these developments are leading, we have released an alpha version of openHAB 2.0 today. Let me share some first results with you:

Configuration UI


A prerequisite for providing user interfaces for configuration is that there is a formal way of describing functionality. For this, the new concept of a “Thing” has been introduced in Eclipse SmartHome. Things build the foundation for the new configuration UIs. They are formally described and provide a lot of meta-data about their functionalities. Things represent the physical devices that can be added to the system and also (web) services that offer certain functionality.

Paper UI showing auto-discovered things
As such, one major feature is the auto-discovery of things: The user does not need to know IP addresses or other ids, but devices can be automatically added. Together with their formally described functionality, this can indeed mean zero effort for first steps.

As a new user interface that also supports dealing with things and their configuration, there is a prototype currently being developed by Dennis Nobel, which is HTML5 based and follows Google's material design. Just as the latest Android 5.0 Lollipop, it uses paper elements and is thus called the “Paper UI”. Although it is still in a very early prototype stage, it is a nice mean to use the new configuration features. You can see it in action in this screencast.

Embedded Platforms


Although many users use a Raspberry Pi for openHAB 1.x, it feels a bit sluggish, especially when many different bindings are used.
Used heap of standard openHAB 2 runtime
A significant part of the runtime deals with processing the textual configuration files (incl. rules), which are realized through domain specific languages (DSLs) – requiring them to be parsed by the runtime is not ideal. Once there are the new configuration UIs in place, the textual configuration files could be made optional – while they can be very convenient and powerful for some users, this would also allow minimal setups that do without it. I am currently experimenting with such a minimal runtime, which packages the Paper UI and all new bindings, but comes without DSL support (and thus without sitemaps, so the other UIs cannot be used for the moment).

Used heap of minimal openHAB 2 runtime
A first analysis shows that it very much reduces the required Java heap size and also comes with a much better start up time than the “full” runtime – the goal is that the minimal runtime is nicely usable on an embedded system comparable to the Raspberry Pi Model A(+) with only 256MB RAM.

Note that removing DSL support currently also means that there is no way of defining automation rules. A new rule engine is therefore another topics that is currently worked on. Its vision is to make rules (or parts of them) easily sharable and reusable by others. Again, this should empower average users to set up automation logic through simple UIs – think of something like IFTTT.

There are also other efforts for reducing the footprint of the runtime: The Eclipse Concierge project might be a lightweight alternative to Eclipse Equinox as an OSGi container. Jochen Hiller is doing excessive testing and bug fixing to move this option forward. Another possibility is to go for Java 8 compact profiles, which would allow reducing the size of the JVM itself significantly.

New Bindings

New LIFX binding for openHAB 2.0
The new Thing concept of Eclipse SmartHome means that the API for implementing bindings has changed heavily in comparison to openHAB 1.x. There are hence only a few bindings that are already based on the new APIs. The alpha release package bindings for Philips Hue, Yahoo Weather, Belkin WeMo and LIFX - all of them support discovery and thus make the initial setup very easy. While Philips Hue, Yahoo Weather and Belkin WeMo are all also available on openHAB 1.x, the LIFX binding is the first one that exclusively exists for the new version.

Future Plans for openHAB 1.x vs. 2.x

With so much efforts going into openHAB 2, you might wonder how the future looks for openHAB 1. Well, the openHAB 1.x core runtime has been very stable and thus did not see much evolution during the last two releases. We will keep it this way and will only concentrate on security fixes and critical patches from now on. Note that this is only the case for the core runtime – all 1.x add-ons, i.e. bindings, actions, persistence services, etc. are very actively maintained and we ask our community members to not slow down here.
For the latest cutting-edge features, we want to encourage the users to switch to the openHAB 2 runtime though, once a first production release is out. One important feature is the 1.x compatibility layer, which should help making openHAB 1 add-ons working on the openHAB 2 runtime. With the current alpha release, we want to engage the our community in testing this layer – the goal is to quickly reach a good compatibility with all existing add-ons, so that there should be no reason not to move to the new runtime and benefit from its new features.

That much about the users, but what about add-on developers? Should they start migrating their 1.x add-on to 2.x? Well, there is absolutely no rush to port them to the new 2.x APIs - especially as there are only new APIs for bindings so far, but nothing yet for actions, persistence services or other types of add-ons. Even for bindings you have to be aware that the new APIs are not yet stable and are likely to change over time. Nonetheless, if you start a completely new binding for openHAB, you are encouraged to go for openHAB 2 directly - especially, if your devices can be discovered and formally described. A positive side effect of implementing a binding against the new APIs is the fact that your code is potentially automatically compatible with other Eclipse-SmartHome-based systems. Besides developing and contributing it to openHAB 2, you could also consider to directly contribute it the the Eclipse SmartHome project - but please note that there are some stricter requirements.
To sum things up: The journey of openHAB continues to be very exciting - and as always, there are so many great ideas, that are waiting to be implemented for the next release!


by Kai Kreuzer (noreply@blogger.com) at November 24, 2014 07:34 PM

Eclipse Dev: Using GtkInspector to analyse Eclipse’s widgets.

by Leo Ufimtsev at November 24, 2014 03:44 PM

As Eclipse developers, when troubleshooting Eclipse, it is sometimes important to figure out how parts of a U.I are constructed.

GtkInspector

Usually, you would use the plugin spy (alt+shift+f1/alt+shift+f2) to see a menu with info about the widget under the mouse.

As of Gtk3~ish , you can in addition fire up the GtkInspector to see how the widget is constructed on the GTK side. The shortcut key for this is ctrl+shift+d (or i) in any gtk3 application.
You might have to launch Eclipse in Gtk3 for the inspector to function. To do this you can set the global gtk3 variable and launch Eclipse:

SWT_GTK3=1
eclipse

More info can be found in this post:
http://blogs.gnome.org/mclasen/2014/11/23/gtk-inspector-update/



by Leo Ufimtsev at November 24, 2014 03:44 PM

Say hello to JEP 220

by Andrey Loskutov at November 23, 2014 11:08 PM

Java tool makers, unite be aware about upcoming changes in Java 9!

This Java version will introduce new file format for class file containers, change the entire JDK installation directory layout and, which is much more important, rt.jar / tools.jar will be gone. Instead, we will have a new "jrt:/" java runtime file system implementation, modules and 3 (or more) .jimage files. The changes are described in details in JEP 220 [1], you can already download Java 9 early access builds containing jigsaw changes [2] and you can participate in the discussion of various aspects via jigsaw-dev mailing list [3].

Why this is important and why should you care?

JDK 9 will be the first JDK which classes could not be inspected with "standard" tooling (emacs, zip, etc), because it introduces a new binary container format (jimage) which replaces old "jar" (zip) container format.

JDK 9 will be the first JDK which classes could not be found without the help of the JDK itself (or new tooling using new "jrt:/" java runtime file system, see [4]). JDK 9 changes the old "jars/packages" hierarchy by adding a new layer to it - modules. The JDK classes will be not only stored in the new jimage files under JAVA_HOME/lib/modules/, they will belong to different modules which names has to be known before accessing class files via "jrt:/".

For example the java/lang/Class.class "file" previously located inside JAVA_HOME/jre/lib/rt.jar will be physically stored inside the JAVA_HOME/lib/modules/bootmodule.jimage, will be "logically" located in the "java.base" module and so accessible at runtime via the "jrt:/java.base/java/lang/Class.class" url:

$java9/bin/jimage list ../lib/modules/bootmodules.jimage | grep java/lang/Class.class 
$java/lang/Class.class

$java9/bin/jdeps -module java.lang.Class 

$java.base -> java.base $ java.lang (java.base)

Right now there is no way for the 3rd party tooling to lookup the single .class file by its name in the new jimage files without first traversing and enumerating the entire "jrt:/" file system via jigsaw-jrtfs tool [4], because the "package to module" association is not available yet for 3rd party tools in JDK 9. The discussion how to lookup a .class file from JDK 9 from tools running on older JDK is ongoing [5].

TL;DR

The changes proposed in JEP 220 are most likely breaking for all low level, .class file / bytecode oriented tools like FindBugs. If you are the tool maker of such a tool, plan for a change now, read specs and discuss open issues on jigsaw-dev before it is too late.

[1] http://openjdk.java.net/jeps/220

[2] https://jdk9.java.net/jigsaw

[3] http://mail.openjdk.java.net/pipermail/jigsaw-dev

[4] https://github.com/forax/jigsaw-jrtfs

[5] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2014-November/004050.html


by Andrey Loskutov at November 23, 2014 11:08 PM

Building P2 Repository using Maven Tycho

by Its_Me_Malai (noreply@blogger.com) at November 22, 2014 09:56 AM

Building P2 Repository using Maven Tycho

Step 1. Create a General Project using File > New > Others > General > Project.


Step 2. Convert the General Project to Maven Project
a. Right Click on the Plugin Project > Select Configure > Convert to Maven Project



Step 3. Wizard to create pom.xml would Open. Configure the same as mentioned below

a. Change the version from 0.0.1-SNAPSHOT to 1.0.0-SNAPSHOT
b. Change Packaging from jar to eclipse-repository.



Step 4. Adding Repository project to parent pom.xml as Module

a. Click on Add.. button in the Modules section


b. Select the modules to include and dnt forget to check the option “Update POM parent section in selected projects.”
c. Open the module pom.xml to see parent information added in the pom file as shown below


Step 5. Right Click on Repository project and Select Maven > Update Project to fix the errors on the Project.

Step 6. Create a Category Definition file from File > New > Others > Category Definition. To this Category Definition, Create the Category and Add your Feature Project. Having the Category Definition file at the root of the Repository Project is mandated to generate the P2 Repository.

Step 7. Now run the parent pom.xml by Right Click, Run As > Maven Install. Your final output would look like


by Its_Me_Malai (noreply@blogger.com) at November 22, 2014 09:56 AM

CDT in the New World

by Doug Schaefer at November 19, 2014 05:12 PM

An interesting thing happened the other day which I think shakes some of the foundation I’ve had in my mind about the CDT. My vision was always for CDT to support C, C++, and related languages on every platform. And that has always included Windows. Mind you, we’ve never really done a great job there but we do have lots of users using it with Cygwin or MinGW and you can argue how well they support Windows application development.

The big news was Microsoft’s Visual Studio Community Edition which is a free version of their complete IDE for individuals and small teams. This is different from their Express editions which were severely limited in the end, including lack of 64-bit support, and the inability to install plug-ins into the IDE. No, the community edition is the full thing and is a pretty important step for Microsoft as they try to keep developer interest in their platform.

As long as Microsoft charged money for Visual Studio, I always thought CDT had a play. I’ve done a little work on supporting integration with their Windows SDK (which includes a 64-bit compiler) at least for build. Debug was always a big hurdle since you’d need to write a complete debugger integration that is very different from gdb. So, really, this integration barely worked. And now that VS is essentially free to the market we serve, there’s little point at continuing that effort. The same is essentially true with Objective-C support with Xcode on Mac, which even they are drifting away from to focus on their new language Swift.

But you know, despite giving up on a dream, I think CDT has an important role to play in it’s field of strength, i.e. support for the GNU toolchain, especially as used for embedded development with it’s new found focus as a pillar in the Internet of Things. As I’ve talked about on Twitter and on CDT forums, I am working on a CDT integration to support building C++ apps for Arduino. Once that’s done, I’ll shift focus to a more complicated environment around Raspberry Pi which I hope to add better remote debug support to CDT. Yes, I know everyone loves to talk about using scripting languages on the Pi, but I want to expose these hobbyists to the real world of embedded which is almost exclusively C and C++, and get them started using CDT.

I still haven’t given up on the desktop, at least desktop support with Qt. I really want to make CDT a first class alternative for Qt development. We have a good start on it and will continue with things like a project file editor, easier setup of builds, and import of projects from Qt Creator. The great thing about Qt is that it also is truly cross platform, allowing you to write your app to run on the desktop and then migrate it to your embedded device, such as the Raspberry Pi. And supporting both of these with the same project is one thing CDT is pretty good at, or at least will be once we fix up the UX a bit.

In the past, much like the rest of the Eclipse IDE, I think we on the CDT have focused a lot on being a good platform, almost too much. While vendors have done a great job at bringing the CDT to their customers writing for their platform, including my employer :), aside from the Linux community, few of us work on supporting the direct user of the Eclipse C/C++ IDE. I think focusing on CDT’s areas of strength and targeting specific open environments and not chasing dreams will help me contribute to the CDT in ways that will actually help the most people. And that’s most satisfying anyway.


by Doug Schaefer at November 19, 2014 05:12 PM