Toggle Line Numbers in Eclipse

by waynebeaton at March 30, 2015 09:46 PM

I’ll admit that I’m dumbfounded by how much people care about whether line numbers are on or off by default in Eclipse. Put the cursor into the gutter area to the left of the editor and right-click to bring up the context menu, select “Toggle Line Numbers” to change the state to match your preference.

Toggle Line Numbers

Most of the standard packages have line numbers turned on by default starting with Luna.

If you’d rather conserve screen space, you can just leave them off and use ctrl+L (cmd+L on the Mac) to jump to a line.

Hit ctrl+L (or cmd+L) to jump to a particular line

Or just use the debugger.

I’d love to hear what you think about everything except whether or not line numbers should be on or off by default (seriously, it’s done: time to move on). I’ll be at Devoxx France in Paris next week. Attend my talk, or visit me at the Eclipse Foundation booth (joined by Obeo and Codenvy).



by waynebeaton at March 30, 2015 09:46 PM

OSGi Subsytems on Apache Felix

by David Bosschaert (noreply@blogger.com) at March 30, 2015 05:09 PM

Note: more up-to-date information on getting started with Apache Aries Subsystems can be found here: http://aries.apache.org/modules/subsystems.html

Last year I blogged about running the OSGi Subsystems implementation from Apache Aries. At the time Equinox was the only OSGi framework that had the full Core R5 implementation supported, which is needed in order to run OSGi Subsystems.

With some recent work on the Apache Felix container, it is now very close to supporting the full OSGi R5 specification. One of this first things that I tried with that is to run the Aries Subsystems implementation on it. And it works :)

OSGi Subsystems are a great way to package a number of OSGi bundles together, for example if you want to distribute an OSGi-based application. Subsystems provide a really convenient deployment model, without compromising the modularity of your application. For more background on Subsystems, see my earlier post about how to use OSGi Subsystems to deploy your applications.

What I'm doing here is take the example from that blog post and run it on Apache Felix with Aries Subsystems.

First of all you need the latest and greatest Felix Framework. I always build it as follows:

  svn co http://svn.apache.org/repos/asf/felix/trunk felix
  cd felix/framework
  mvn install 
  cd ../main
  mvn install 

This will give you a framework runtime in the felix/main folder.
Then add the following bundles to the bundle subdirectory:

All of the bundles above have links behind them where they can be downloaded, except for the Felix Coordinator implementation, as this one is very new. You can just build it from the coordinator directory of your Felix checkout. Or, if you prefer to use released components, you can also use the Equinox implementation org.eclipse.equinox.coordinator_1.1.0.v20120522-1841, but in order to run that on Felix you also need the Equinox supplement bundle org.eclipse.equinox.supplement_1.5.0.v20130812-2109.
Finally, I'm adding my little gogo command bundle as described in my older post, to add subsystem:list, subsystem:install, subsystem:uninstall, subsystem:start and subsystem:stop commands to Gogo. You can also download that as a bundle here: subsystem-gogo-command-1.0.0.jar

Ok, let's start up Felix and look what's inside:
.../felix/main $ java -jar bin/felix 
... some log messages appear ...
____________________________
Welcome to Apache Felix Gogo
g! lb
START LEVEL 1
   ID|State      |Level|Name
    0|Active     |    0|System Bundle (4.3.0.SNAPSHOT)
    1|Active     |    1|Apache Aries Application API (1.0.0)
    2|Active     |    1|Apache Aries Application Modelling (1.0.0)
    3|Active     |    1|Apache Aries Application Utils (1.0.0)
    4|Active     |    1|Apache Aries Blueprint Bundle (1.1.0)
    5|Active     |    1|Apache Aries Proxy Bundle (1.0.1)
    6|Active     |    1|Apache Aries Subsystem API (1.0.0)
    7|Active     |    1|Apache Aries Subsystem Core (1.0.0)
    8|Active     |    1|Apache Aries Util (1.1.0)
    9|Active     |    1|Apache Felix Bundle Repository (1.6.6)
   10|Active     |    1|Apache Felix Configuration Admin Service (1.8.0)
   11|Active     |    1|Apache Felix Coordinator Service (0.0.1.SNAPSHOT)
   12|Active     |    1|Apache Felix Gogo Command (0.12.0)
   13|Active     |    1|Apache Felix Gogo Runtime (0.10.0)
   14|Active     |    1|Apache Felix Gogo Shell (0.10.0)
   15|Active     |    1|Apache Felix Resolver (1.0.0)
   16|Active     |    1|Region Digraph (1.1.0.v20120522-1841)
   17|Active     |    1|slf4j-api (1.7.5)
   18|Resolved   |    1|slf4j-simple (1.7.5)
   19|Active     |    1|Subsystem Gogo Command (1.0.0)
   20|Active     |    1|org.osgi.service.subsystem.region.context.0 (1.0.0)

g! subsystem:list
0 ACTIVE org.osgi.service.subsystem.root

Looking at the bundles, you can see the Gogo command line ones that come with Felix, as well as its Bundle Repo. You can also see bundle 20, which is a synthesised bundle that the Subsystems implementation added and which represents the root subsystem. The subsystem:list command reports that there is one subsystem: the root one.

Now let's look at my example applications again. I have the following two subsystems:


Subsystems are a great way to distribute multi-bundle applications, and my two subsystems each contain 2 specific bundles as well as a shared bundle.

Let's install then and see what happens:

g! subsystem:install http://coderthoughts.googlecode.com/files/subsystem1.esa
Installing subsystem: http://coderthoughts.googlecode.com/files/subsystem1.esa
Subsystem successfully installed: subsystem1; id: 1
g! subsystem:start 1
g! lb
START LEVEL 1
   ID|State      |Level|Name
...
   21|Active     |    1|SharedBundle (1.0.0)
   22|Active     |    1|BundleA (1.0.0)
   23|Active     |    1|BundleB (1.0.0)
The three bundles needed by subsystem1 are installed and all started with the subsystem:start command.

And let's add the second subsystem...
g! subsystem:install http://coderthoughts.googlecode.com/files/subsystem2.esa
Installing subsystem: http://coderthoughts.googlecode.com/files/subsystem2.esa
Subsystem successfully installed: subsystem2; id: 2
g! subsystem:start 2
g! lb
START LEVEL 1
   ID|State      |Level|Name
...
   21|Active     |    1|SharedBundle (1.0.0)
   22|Active     |    1|BundleA (1.0.0)
   23|Active     |    1|BundleB (1.0.0)
   24|Active     |    1|BundleC (1.0.0)
   25|Active     |    1|BundleD (1.0.0)

As expected, the two new bundles for subsystem2 are now also installed. And, because we're talking about a feature subsystem here, where everything is shared, the SharedBundle (21) is not installed a second time, but rather reused from subsystem1. 

The topic of subsystems is much bigger. Subsystems can provide a certain level of isolation, they can work with Repositories for provisioning and you have a lot of options wrt to what you can put inside an .esa file: you can put all the bundles in there that your application needs, or you can just have a textual descriptor that declares your main bundles and let the OSGi Resolver and Repository find the dependencies and deploy these for you. Details about these various options can be found in the OSGi Subsystem spec (chapter 134 in the OSGi R5 Enterprise spec). 

All in all good news - Subsystems now works in Apache Felix as well. Right now you need to build the latest snapshot, but hopefully we'll have a Felix Framework release for this soon!

by David Bosschaert (noreply@blogger.com) at March 30, 2015 05:09 PM

Upcoming Docker Tooling for Eclipse

by xcoulon at March 30, 2015 04:45 PM

JBoss Tools and Eclipse Linux Tools team members from Red Hat are currently busy working on Docker tooling for Eclipse and even though the code is not public yet (more details on that at the end of this blog entry), I thought it would be interesting to share our progress on the project.

The Docker tooling is aimed at providing at minimum the same basic level features as the command-line interface, but also provide some advantages by having access to a full fledged UI.

Docker Explorer

The Docker Explorer provides a wizard to establish a new connection to a Docker daemon. This wizard can detect default settings if the user’s machine runs Docker natively or in a VM using Boot2Docker. Both Unix sockets on Linux machines and the REST API on other OSes are detected and supported. The wizard also allows remote connections using custom settings.

Connection wizard

The Docker Explorer itself is a tree view that handles multiple connections and provides users with quick overview of the existing images and containers.

Docker Explorer view

Built-in filters can show/hide intermediate and 'dangling' images as well as stopped containers.

Managing Docker Images

The Docker Images view lists all images in the Docker host selected in the Docker Explorer view. This view allows user to manage images, including:

  • Pulling images from the Docker Hub Registry (other registries will be supported as well)

  • Uploading images to the Docker Hub Registry

  • Building images from a Dockerfile

  • Creating a container from an image

Docker Images view

A wizard lets the user input all the arguments to create a new container from an image. When the container is started, all the logs can be streamed into the Eclipse Console:

Docker Images view

Managing Docker Containers

The Docker Containers view lets the user manage her containers. The view toolbar provides commands to start, stop, pause, unpause, display the logs and kill containers.

Docker Containers view

This view also provides a filter to show/hide stopped containers. Users can also attach an Eclipse console to a running Docker container to follow the logs and use the STDIN to interact with it.

Info and Inspect on Images and Containers

We also integrate with the Eclipse Properties view to provide users with info and 'inspect' data about a selected container or image.

Properties view

Where is the code ?

Roland Grunberg and Jeff Johnston from Red Hat started this project and are currently in the process of getting the code accepted to Eclipse.org as part of the Linux Tools project (even if the tooling also runs on other platforms), which explains why the code has not been made public yet.

Taking about code, we rely on the open source Docker client developed by Spotify to handle the low-level communication with the Docker daemons and I should thank the Spotify developers who maintain this library. They’ve been very kind to quickly review and merge the pull requests that we’ve submitted and it’s been a pleasure to contribute to their project. Open source collaboration FTW :-)

What’s next ?

There is still some work and the screenshots showed above may still evolve as we add more features, but we hope that this blog entry will give you a taste of what’s coming soon in Eclipse with regards to Docker tooling.

While the code will be hosted in Linux Tools project at Eclipse.org, we intend to also ship it as part of JBoss Developer Studio 9 and JBoss Tools 4.3 later this year.

We also created a JIRA component to track this work-in-progress in the scope of JBoss Tools, including some issues with mockups.

Beyond this basic Docker tooling we are looking at integrating launching servers and even native CDT builds on docker containers, but this will be the subject of future posts on this blog ;-)

As usual, feel free to provide us with feedback on our forum, on JIRA or on IRC. Questions, comments and suggestions are always welcome!

Stay tuned!

/Xavier
@xcoulon


by xcoulon at March 30, 2015 04:45 PM

Branding Eclipse Products

by Vladimir Prus (noreply@blogger.com) at March 30, 2015 12:50 PM

Last year we worked on a new Eclipse-based IDE, in particular creating product branding from scratch. Despite visual editors and several existing online tutorials, that still proved confusing, so I've decided to documented what we've learned.

In this post, we'll review branding of a simple product. It has:
  • One functional plugin, and one functional feature including that one plugin
  • One product plugin and one product feature including the product plugin and functional feature
  • Product configuration
To make things simpler:
  • I use artwork we used in our products.
  • There's no localization of strings
  • The welcome/intro screen is almost neglected, since we use custom HTML for that, and it might be best approach for any new product.
Of course, I assume you know what is plugin and what is feature.

Functional features

Functional feature, along with contained plugins, implements some useful behavior that you can potentially install into any Eclipse-based product. For example, EGit feature is equally useful for Java and C++ IDE. For proprietary products, it is often tempting to just mix everything together, but creating separate features is often beneficial. The first example is of exactly such standalone feature, see sources

The important files in the plugin are META-INF/MANIFEST.MF, about.ini and about.html. For the feature, feature.xml and about.html are important. In particular, feature.xml relays most of the branding to a 'branding plugin', which, in our case, is the lonely functional plugin. 

Starting with that source, you can import it into your PDE, click on feature.xml, export feature into a directory, install it into a second Eclipse installation, and then "Help->About" dialog will look like this:

In the row of icons that represent feature providers, there is our "crystal ball" logo. The icon is defined by the branding plugin, via featureImage attribute in about.ini. Should you have multiple feature with the same icon (pixel-wise), they will be merged in this dialog. Clicking "Installation Details" gives us in-depth information:
This dialog shows root P2 installable units in the Eclipse instance. The 'name' column is taken from 'label' attribute of feature.xml, and the description below comes from the 'description' element in feature.xml.  The same description is shown when installing the feature. We can also use the "Properties" button to see more details from feature.xml, like copyright and license:
The above is fairly reasonable. The features tab, however, brings some surprises:
The "Feature Name" column is coming from branding plugin, the Bundle-Name attribute of MANIFEST.MF. The description below is composed from 'label' attribute in feature.xml and 'aboutText'  attribute in plugin's about.ini. The icon is also coming from about.ini - and if you specify icon attribute in feature.xml, it is ignored. Finally, the "License" button opens about.html file in the feature directory - which is generally different from license attribute in feature.xml. Clicking the "Plug-in Details" button shows branding information for plugins, which is rather simple:
The "Provider" and "Plug-in Name" fields correspond to Bundle-Vendor and Bundle-Name in MANIFEST.MF. The "Legal Info" button opens about.html in plugin's root directory. As an aside, I'm not sure why it's called "License" for features and "Legal Info" for plugins and "License Agreement" for installable units.

Products

Products put together a set of functional features that make sense for a particular audience, and add particular overall branding. Physically, product consists of a product feature and product plugin, organized the same way as functional feature and plugin. The example source for that is here, which you can again import into PDE, export into P2 repository, and install into separate Eclipse instance, and then run it with the "-product com.codesourcery.seed.product.product" command-line option.

The key element of product branding is this extension in plugin.xml:
<product name="Example Eclipse Product" application="org.eclipse.ui.ide.workbench">
    <property name="appName" value="Example Eclipse Product"/>
    <property name="windowImages"  value="images/csl16.png,images/csl32.png,images/csl48.png"/>
    <property name="aboutImage" value="images/IDE_about.png"/>
    <property name="aboutText" value="About text for the example product."/>
    ...
</product>
The first two properties define outside appearance of the product - it's name, shown in the window title, and its icon, shown in taskbar, or launcher, or window switcher, depending on your OS. The other two attributes affect the about dialog box, making it look like below:
Now it actually looks like a custom product! The installation details in this case are almost the same, except that it has two features, one depending on the other:
There are several other properties in product definition that are related to welcome screen, but as I've said, we replace it completely, so I'm not going to describe it. The example source code has some definitions if you're interested.


Launcher and Product Build
The product feature we've built can be exported from PDE (or built with Maven, if you wish), and installed into Eclipse, but we usually want to build a complete product that can be immediately run. We need product configuration (.product file) for that, and it's covered in detail elsewhere. As far as branding goes, we only need two details:
  • Showing custom splash screen on startup
  • Starting our product
The product configuration specifies them in fairly direct way - the product is specified as attributes of the top-level 'product' element, and the splash screen becomes a command-line attribute to the launcher. In the exported product directory, two files control this behaviour. First, the eclipse.ini files in the root directory contains '-showsplash com.codesourcery.seed.product' for the splash screen. Second, the 'configuration/config.ini' specifies the product to run. That almost completes our product branding. 

Almost, because while product extension point can specify window icon and similar properties, the .product file also can specify those. When you do product export in PDE, the properties from .product files are copied into product extension point, so unless you duplicate them, you get product with no window icons. This problem is accounted for in the final version. We don't have this problem in practice, since we built the final product from the command line, and so splash screen and product id is the only branding we need in the '.product' file.


Do it yourself
I have put together a seed Eclipse product over at GitHub, and you are free to use it if you are creating a new product. I would suggest these tips:
  • Use high-resolution artwork, preferably created from vector originals, and keep those originals.
  • Having license in every about.html and every feature.xml is awkward. Either automate it, or refer to documentation for license terms.
  • Use the same label for each functional feature and its branding plugin
  • If you can get HTML support working on your target systems, use custom HTML instead of default welcome screen.
Hope this help!

Acknowledgements

Dmitry Kozlov has worked with me on this, while Sourcery Services allowed me to take time to summarize our experience.




by Vladimir Prus (noreply@blogger.com) at March 30, 2015 12:50 PM

Yet Another Maven Bundle Plugin!

by Peter Kriens (noreply@blogger.com) at March 30, 2015 07:30 AM

It must have been 8 years ago that Richard S. Hall visited me here in the south of France. During these days we hacked together a rudimentary plugin for Maven so that Richard could use bnd's functionality in his maven build. This was where we laid the foundation for the "funky" XML that described the bundle. As this was our first maven plugin, we had no clue what we were doing but it seemed to

by Peter Kriens (noreply@blogger.com) at March 30, 2015 07:30 AM

JavaLand 2015

by Kai Tödter at March 28, 2015 09:00 AM

Last week I attended the JavaLand conference (March 23-24, 2015) and this is a short personal blog about it.

The Venue

The conference took place at Phantasialand, a great theme park in Brühl, close to Cologne. I really liked the atmosphere there, it reminded me a lot of Disneyland, which I visited 6 months ago. The sessions were held both in the Quantum conference center, as well as the movie theater and the main stage. At the end of the first conference day, 11 attractions of the park were opened just for the conference attendees. I took the advice of some friends very seriously: Don’t drink a beer until you have finished all the rides! When I was younger, I was a big roller coaster fan, so I tried Black Mamba, Colorado Adventure and Temple of the Night Hawk. Then I had enough of roller coasters :).

javaland-panorama

The Sessions

For many conference attendees the sessions are the most important part of a conference. In my point of view the sessions were a good mix of technical and non-technical topics. Since I am a Java veteran for 20 years, I usually only attend sessions about content that is either totally new for me or I have very little knowledge about. My personal highlights were:

  • Coding Culture (by Sven Peters)
  • Effective Asciidoc (by Dan Allen and Sarah White)
  • Use Cases for Elasticsearch (by Florian Hopf)

Of course there were many more great talks but these 3 gave me new insights and made me think most. My own session about TypeScript went well, hopefully I could transport my excitement about TypeScript to the audience. I really appreciated that other programming languages got some attention at the conference.

session-panorama

The Community

I really liked the atmosphere at the conference. It was very easy for me to talk to people I did not know before. In the community area there were lots of interesting booths, playgrounds, open spaces, katas, workshops and more. It was fun to experience a few Oculus Rift demos that I did not know before. It was also very nice to meet old friends like Wayne Beaton and Lars Vogel from the Eclipse community, as well as many people I know from my JCP work or other conferences.

The Food

While many developers are happy if they get pizza or fast food, I appreciate good catering at conferences. I was invited to the community dinner on Monday, hosted in the restaurant of one of the theme hotels. This dinner was the start of great catering during the whole conference, so JavaLand easily made it into my all-time top 5 conference caterings.

The Band

I have to admit that I did not expect anything when I heard a band was playing Tuesday night. To make it short: The Band (Sonnabend) was awesome! After enjoying few songs I could not resist to dance for more than one hour. 20 years ago I played keyboards in my Band DC Robertson (see MultiMedia) so I had a special eye on the awesome keyboarder :).

band-panorama

Opportunities

There were a few things that I was missing: Reliable Wifi and a conference app. Another thing: When I attended sessions in the theater, it was pretty chilly. So, as always, there is room for improvements :).

Summary

All in all I liked the conference a lot and looking forward to JavaLand 2016.

Flattr this!


by Kai Tödter at March 28, 2015 09:00 AM

Less than a week to contribute your Great Fix for Mars

March 27, 2015 02:21 PM

The contributors with the best fixes will be awarded a new Nexus 9 tablet! Next deadline is April 1.

March 27, 2015 02:21 PM

Announcing the bnd Maven Plugin

March 27, 2015 12:00 PM

I am pleased to announce the availability of a new Maven plugin for building OSGi bundles, based on bnd. The plugin is called bnd-maven-plugin and it will be developed as part of the wider bnd and Bndtools projects.

The plugin has been kindly donated by one of Paremus’ customers – a very well known company whose identity we expect to be able to confirm in due course – under the terms of the Apache License version 2.

You might very well wonder: why did we build a new Maven plugin for OSGi development? Most OSGi developers who use Maven today are using the maven-bundle-plugin from Apache Felix. That plugin is mature and stable but it does have a number of issues that our customer wanted resolved.

The first major issue with maven-bundle-plugin is that it replaces Maven’s default plugin for JAR generation (the maven-jar-plugin). This means that it must use a different packaging type – “bundle” instead of “jar” – and must use the extensions=true setting to override Maven’s default lifecycle. As a result, the output artifacts are harder to consume in ordinary non-OSGi projects. Therefore, many Maven developers either don’t bother to release OSGi bundles at all because of the hassle, or they release both a “plain JAR” and a separate OSGi bundle. This is deeply frustrating because OSGi bundles already are plain JARs!… they can be used unalterered in non-OSGi applications.

The new bnd-maven-plugin instead hooks into Maven’s process-classes phase. It prepares all of the generated resources, such as MANIFEST.MF, Declarative Services descriptors, Metatype XML files and so on, under the target/classes directory, where they will be automatically included by the standard maven-jar-plugin (with one caveat discussed below).

The second issue is that maven-bundle-plugin has some questionable features and design choices. For example it automatically exports all packages that do not contain the substrings “impl” or “internal”. The motivation was understandable at the time – it is closer to normal Java with all packages being implicitly exported – but this is really just wrong from a modularity point of view, and goes against OSGi best practices. The bnd-maven-plugin instead includes all packages from the project in the bundle but exports nothing by default. The developer must choose explicitly which packages are exported.

The third issue with maven-bundle-plugin is that it is difficult to use in an incremental build environment. In Bndtools we have had literally years of discussions about how to best accommodate Maven users while still supporting the rapid development cycle that Bndtools users love. The new plugin will make this easier: for example after the process-classes phase has completed, the content of the target/classes directory is already a valid OSGi bundle, albeit in folder form rather than a JAR file. Also the new plugin takes its bnd instructions from the bnd.bnd file in each project, rather than from a funky XML encoding of those instructions deep inside the POM.

Finally, we believe that by delivering a Maven plugin directly from the bnd project, we can more quickly take advantage of new features in bnd, and develop features in bnd that directly benefit Maven users. Note however that the Gradle and Ant integrations of bnd will still be supported: we want everybody to use bnd to build their OSGi bundles, irrespective of IDE and build system.

So much for motivation, let’s look at some of the technical details.

The plugin has been released as version 2.4.1 because there was a previous experimental plugin with the same name. That experiment was not a success, and we abandoned it some time ago – the new plugin is a complete rewrite. The version of the plugin will track the version of bnd itself, so 2.4.1 of the plugin builds against 2.4.1 bnd, which is released and available from Maven Central. From now on we will work on version 3.0, which will track version 3.0 of bnd.

The plugin generates the JAR manifest into target/classes/META-INF/MANIFEST.MF, but due to a limitation of the maven-jar-plugin this file is ignored and replaced by an empty, non-OSGi manifest. We are preparing a patch against maven-jar-plugin to modify this behaviour and hope that it will be accepted, but in the meantime it is necessary to set the following configuration one time in your parent POM:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-jar-plugin</artifactId>
    <configuration>
        <archive>
            <manifestFile>${project.build.outputDirectory}/META-INF/MANIFEST.MF</manifestFile>
        </archive>
    </configuration>
</plugin>

The plugin is available now from Maven Central or jCenter. It is not yet thoroughly documented, although bnd itself does have very good documentation. All options from bnd automatically work in bnd-maven-plugin, with the exception of “sub bundles” (-sub) since Maven projects are meant to produce exactly one output artifact per project.

To add the plugin to your project, insert the following into your POM:

<plugin>
    <groupId>biz.aQute.bnd</groupId>
    <artifactId>bnd-maven-plugin</artifactId>
    <version>2.4.1</version>

    <executions>
        <execution>
            <goals>
                <goal>bnd-process</goal>
            </goals>
        </execution>
    </executions>
</plugin>

We have example projects to get started. Questions, problems or offers of help can be can be directed to the bnd/Bndtools mailing list.


March 27, 2015 12:00 PM

Open IoT Challenge – Final submissions

by Benjamin Cabé at March 26, 2015 05:55 PM

The Open IoT challenge ended earlier this week, and it was pretty exciting to see the final submissions coming in the form of blog posts and video during the last hours before the deadline.

Below are the 10 projects who validated their participation to the challenge, together with the links to learn more about what they have built during the 2 months the challenge lasted. Exciting stuff!

Carracho

The project aims to build an advanced monitoring car system, integrating the huge amount of sensors data from the car ECU (read by standard OBD-II interface) with smartphone sensors data (like GPS). A gateway (a Raspberry Pi with Kura OSGi framework) can collect the data, wrap them in a MQTT packet and finally send them to a remote MQTT server exploiting the 3G connection provided by the smartphone (the latter could be connected to the Raspberry Pi with bluetooth interface).

→ Read more: http://diyapps.blogspot.com/2015/03/eclipse-open-iot-challenge-final-post.html

IoNeeds

IoNeeds basically measures fullness, light, temperature and humidity of storage boxes and jars continuously. It stores the data on cloud and when it encounters with extreme values, it applies the rules which previously configured on control panel such as sending SMS, Android/iOS notifications. Also it can be configured with e-commerce web sites’ order APIs. So it enables auto-order scenarios like “Automatically order the product from web if fullness value is under 50%”

→ Read more : http://ioneeds.com/2015/03/final-ioneeds-is-working-now/

DIY Home Automation

A DIY “home automation” solution based on MQTT-SN, Node-RED, Arduino, Raspberry Pi and nRF24L01+ RF transceivers.

→ Read more: http://openiotchallenge.tumblr.com/post/114361695760/project-wrap-up

Raspberry Pi R/C car

Program a remote controlled Raspberry Pi Robot car using Reactive Blocks.

→ Read more: http://www.bitreactive.com/remote-controlled-raspberry-pi-car-part-3-2/

watr.li, Internet of Plants

Keeping plants alive in an office without regular hours is hard: Either everybody thinks their colleagues have already watered the plants or multiple people water the same plant, resulting in either drought or overhydration.

→ Read more: http://watr.li/wrapup.html

Hot Desking Dilemma

More and more companies offer their employees the possibility to work remote from home instead of working in the office. Hot desking – multiple employees share one desk over a week – is a common practice for such companies in order to reduce costs. People who know this setting also know the downsides of this model: it is just pretty hard to get a desk when you need one.

→ Read more: http://icanseedeadcats.com/2015/03/24/eclipse-iot-challenge-mqtt-communication-for-hot-desks-featuring-kura-mosquitto-and-paho-and-project-wrapup

LwM2M over MQTT

The current stack for LWM2M relies on CoAP as the protocol. Along with CoAP, MQTT is another standard which is being very widely used in M2M scenarios. Our solution involves development of an LWM2M server prototype, as well as, a client prototype, which make use of MQTT as the underlying M2M protocol. Thus LWM2M can be used for both CoAP, as well as, MQTT.

→ Read more: http://openiotchallenge.tumblr.com/post/112230693320/lwm2m-over-mqtt

Monitoring industrial automation

This project realizes a device that monitors a set of defined parameters (mapped to MODBUS registers on a device) and based on defined rule take action (store in internal memory, show as value or graph on local LCD or send using MQTT protocol to defined server). User is able to freely define mapping to MODBUS registers, poling interval, monitoring rules and actions).

→ Read more: https://tobiddev.wordpress.com/2015/03/24/summary-of-open-iot-challenge-monitoring-industrial-automation-equipment/

Smart Helmet

According to a survey, in India, 139,091 persons were killed in road accidents during the year 2012, out of which 23% constituted for Two-wheeler related incidents. The objective of the solution is to detect impact of the accident or fall occurred using the accelerometer mounted on the helmet.

→ Read more: http://byrebg.blogspot.in/2015/03/smart-helmet-using-eclipse-kura.html

Monitoring snow and ice falling down of roofs

In Norway it is the responsibility of building owners to warn people of risk of snow and ice falling down from the roofs of buildings. It is a serious liability. Some years ago in Oslo, a pedestrian got paralyzed after a iceblock fell from a building and hit his head.

→ Read more: http://openiotchallenge.tumblr.com/post/114484170515/warning-system-for-snow-ice-falling-from-roofs


by Benjamin Cabé at March 26, 2015 05:55 PM

Maven, Tycho, Surefire, AspectJ and Equinox Weaving

by Andreas Graf at March 26, 2015 02:33 PM

This is a very short technical post. But since it took us some time to find the solution (there is little information on the Web), we wanted to add another possible search hit for others.

JUnit tests from within Eclipse work well with AspectJ runtime weaving in Equinox. Finding information on how to activate the same in Maven Tycho surefire was more difficult.

You have to configure the surefireplugin to use the Equinox Weaving hook and start the AspectJ Weaving Bundle:

 

<bundleStartLevel>
							<bundle>
				               	  <id>org.eclipse.equinox.weaving.aspectj</id>
				                 <level>2</level>
				                 <autoStart>true</autoStart>
              				</bundle>
						</bundleStartLevel>
						<frameworkExtensions>
			            <frameworkExtension>
			              <groupId>p2.osgi.bundle</groupId>
			              <artifactId>org.eclipse.equinox.weaving.hook</artifactId>
			      			<version>1.1.100.weaving-hook-20140821</version>
			            </frameworkExtension>
			          </frameworkExtensions>
In addition, on command line configuration, you could pass debug information. We have set the property:
<aspectj.weavingargs>-Daj.weaving.verbose=true -Dorg.aspectj.weaver.showWeaveInfo=true -Dorg.aspectj.osgi.verbose=true</aspectj.weavingargs>
and use it later on
<argLine>${tycho.surefire.vmargs} {aspectj.weavingargs} ... </argLine>

by Andreas Graf at March 26, 2015 02:33 PM

Eclipse Newsletter - Eclipse in Automotive

March 26, 2015 02:22 PM

In this newsletter, you will find an article about Eclipse in Automotive and two articles focusing on Almathea4public and Artop.

March 26, 2015 02:22 PM

Welcome Andrey Loskutov as a new eclipse.platform.ui Committer

by Lars Vogel at March 26, 2015 08:49 AM

I would like to welcome Andrey as new platform.ui committer. Andrey is a very active Eclipse tools developer who maintain popular Eclipse tools like the Eclipse Findbugs plug-in and AnyEdit. And now is is already the second most active developer of platform.ui takeling a bunch of critical and difficult issues.

andrey

Welcome Andrey!

See the message on the platform.ui mailing list. See also Andrey blog post about this topic.


by Lars Vogel at March 26, 2015 08:49 AM

Thoughts on running an open source program (via @TODOGroup)

by Chris Aniszczyk at March 25, 2015 06:05 PM

I recently posted on the @TODOGroup blog on why we run an open source program at Twitter:

Outside of just my experience, it’s been great to see other companies participating in this effort so you can hear from them too on running open source programs:

There should be more blog posts from us in the future about this topic, on top of us discussing other issues pertinent to companies working with open source communities.

Anyways, I hope you learned something new from these posts and if you’re a fan of company open source programs, please consider pushing your company or others to establish an official open source program or office. We all should give back as it’s in our best interest.


by Chris Aniszczyk at March 25, 2015 06:05 PM

FoundationDB and Open Source Foundations

by Chris Aniszczyk at March 25, 2015 03:29 PM

Just like any other day, I saw a funny tweet across my timeline this morning:

Not sure if you heard the news, but FoundationDB was a company with a decent amount of open source projects around a NoSQL database. They recently were bought by a much larger company and decided to close down the project, including removing the source and binaries from distribution channels.

I don’t want to sound like a broken record, but open source foundations are really useful. As a consumer, it helps you ensure that there is an independent governance structure in place along with fair ownership of the code (usually the foundation). This means that code won’t disappear overnight since an independent entity owns it, along with the broader community. From a producer point of view, you can build diversity in ownership and committers which will help you in the long run in building a sustainable open source community.

Oh well, c’est la vie.

Quick update and nice set of genuine tweets from the CouchDB folks who saw the benefits of having the code exist at an open source foundation:


by Chris Aniszczyk at March 25, 2015 03:29 PM

speaking at MobileTechCon 2015

by ekkescorner at March 24, 2015 08:02 AM

mtc15speaker

This week at MobileTechCon I’m speaking about “Secure Workspaces” (Tuesday) and “Bluetooth in Business Apps” (Wednesday)

Secure Workspaces – Islands of Security

  • learn all about BYOD, COPE, COBO, Regulated, MDM, EMM and more
  • live demo BES12
  • get tips what’s important to know about BES12, Airwatch, Good, MobileIron, Samsung KNOX, Android for Work, …

MobileTechCon 2015-03-24, 16:15, Forum 15

Bluetooth in Business Apps

  • new workflows possible for enterprise workflows using iBeacons, Beacons, NFC, Bluetooth LE, ‘old’ Bluetooth
  • live demo Beacons and NFC
  • live demo two devices connected using SPP: Barcode Printer and FingerScanner

MobileTechCon 2015-03-25, 14:30, Forum 15

see you there


Filed under: BB10, Blackberry, Eclipse, mobile

by ekkescorner at March 24, 2015 08:02 AM

Andmore Nightly p2 Repository

by kingargyle at March 24, 2015 12:06 AM

Andmore now has a nightly p2 repository available for Adopters and third party tool providers to start making use.

http://download.eclipse.org/andmore/nightly

This site should contain everything you need to install Andmore into an eclipse environment and start developing android applications.  It can also be used by add on providers to build off and extend Andmore to other tools.   As with all nightly sites, this could be unstable at times, but should be useable to help provide feedback to the project.

Please help kick the tires and provide feed to the project about what is working and what isn’t working.  We need and want your involvement to help improve eclipse android tooling.



by kingargyle at March 24, 2015 12:06 AM

JBoss Integration Stack Tooling - Kepler Update

by pleacu at March 23, 2015 04:16 PM

Just for you Kepler fans - an Eclipse Kepler update of your favorite Integration Stack tooling is now available.

jbosstools jbdevstudio blog header

What’s an Integration Stack?

JBoss Tools Integration Stack 4.1.7.Final / JBoss Developer Studio Integration Stack 7.1.0.GA

The Integration Stack for JBoss Tools Developer Studio is a set of plugins for Eclipse that provides integration 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.1 and Developer Studio 7.

What’s Been Updated?

Updates have been made to the Business Process tooling (BPMN2 Modeler, BPEL), Fuse Tooling and Data Virtualization tooling (Teiid Designer). See the JBDSIS 7.1.0 Release Notes

Released Tooling Highlights

BPEL Highlights

Bug Fixes
  • Cannot set date (deadline expression) in Wait and OnAlarm

Fuse Tooling Highlights

Bug Fixes
  • Hyperlinks in the Fuse Tooling help seem to be widely broken

For more specifics see

Fuse Tooling

See Lars Heinemann’s Blog for more insights.

The JBoss Tools website features tab

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

Installation

If you already have JBDSIS installed…​

Simply start jbdevstudio or eclipse-with-jbds, then:

Select Help > Check for Updates

Select the components you’d like to install from the available updates:

Check for Updates - JBoss Tools Integration Stack

If you’d like a fresh install…​

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…​

Eclipse Marketplace - JBDS

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:

JBoss Central - JBoss Developer Studio Integration Stack

The standard p2 installer is available for JBoss Developer Studio Integration Stack. Simply start jbdevstudio or eclipse-with-jbds, then:

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

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

Eclipse Marketplace - JBoss Tools

Once JBoss Tools is installed, restart Eclipse and select the Software/Update tab in the JBoss Central view. The current 4.1.7.Final integration stack is available automatically. Select the items you’d like to install:

JBoss Central - JBoss Tools Integration Stack

The standard p2 installer is available for JBoss Tools Integration Stack. Simply start eclipse-with-jbt, then:

 Help > Install New Software...
       Add...
       - use this for 'Location:' for the released-components integration stack:
         http://download.jboss.org/jbosstools/updates/stable/kepler/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

Let us know…​

Paul Leacu.


by pleacu at March 23, 2015 04:16 PM

RCP Testing Tool – Tutorial updated

by Jonas Helming at March 23, 2015 03:08 PM

Almost two years ago, I have created a basic tutorial for the UI testing tool “Q7”. In 2014, Q7 has been released as an open source project and been renamed to “RCP Testing Tool” (RCPTT). RCPTT is focused on creating and running UI/System test for RCP/SWT applications. It is an alternative or addition to the open source projects SWTBot or Jubula. All of them have their specific advantages and disadvantages, RCPTT uses a very different approach than that of SWTBot or Jubula. I updated my tutorial based on the latest version of RCPTT, it describes all basic steps to get started with RCPTT. It should also give you a good impression of how RCPTT works.

Please follow this link to get to the new tutorial.


TwitterGoogle+LinkedInFacebook

Leave a Comment. Tagged with eclipse, rcp, testing, eclipse, rcp, testing


by Jonas Helming at March 23, 2015 03:08 PM

Scaling Yosemite

by Kim Moir (noreply@blogger.com) at March 20, 2015 06:52 PM

We migrated most of our Mac OS X 10.8 (Mountain Lion) test machines to 10.10.2 (Yosemite) this quarter.

This project had two major constraints:
1) Use the existing hardware pool (~100 r5 mac minis)
2) Keep wait times sane1.  (The machines are constantly running tests most of the day due to the distributed nature of the Mozilla community and this had to continue during the migration.)

So basically upgrade all the machines without letting people notice what you're doing!

Yosemite Valley - Tunnel View Sunrise by ©jeffkrause, Creative Commons by-nc-sa 2.0

Why didn't we just buy more minis and add them to the existing pool of test machines?
  1. We run performance tests and thus need to have all the machines running the same hardware within a pool so performance comparisons are valid.  If we buy new hardware, we need to replace the entire pool at once.  Machines with different hardware specifications = useless performance test comparisons.
  2. We tried to purchase some used machines with the same hardware specs as our existing machines.  However, we couldn't find a source for them.  As Apple stops production of old mini hardware each time they announce a new one, they are difficult and expensive to source.
Apple Pi by ©apionid, Creative Commons by-nc-sa 2.0

Given that Yosemite was released last October, why we are only upgrading our test pool now?  We wait until the population of users running a new platform2 surpass those the old one before switching.

Mountain Lion -> Yosemite is an easy upgrade on your laptop.  It's not as simple when you're updating production machines that run tests at scale.

The first step was to pull a few machines out of production and verify the Puppet configuration was working.  In Puppet, you can specify commands to only run certain operating system versions. So we implemented several commands to accommodate changes for Yosemite. For instance, changing the default scrollbar behaviour, new services that interfere with test runs needed to be disabled, debug tests required new Apple security permissions configured etc.

Once the Puppet configuration was stable, I updated our configs so the people could run tests on Try and allocated a few machines to this pool. We opened bugs for tests that failed on Yosemite but passed on other platforms.  This was a very iterative process.  Run tests on try.  Look at failures, file bugs, fix test manifests. Once we had to the opt (functional) tests in a green state on try, we could start the migration.

Migration strategy
  • Disable selected Mountain Lion machines from the production pool
  • Reimage as Yosemite, update DNS and let them puppetize
  • Land patches to disable Mountain Lion tests and enable corresponding Yosemite tests on selected branches
  • Enable Yosemite machines to take production jobs
  • Reconfig so the buildbot master enable new Yosemite builders and schedule jobs appropriately
  • Repeat this process in batches
    • Enable Yosemite opt and performance tests on trunk (gecko >= 39) (50 machines)
    • Enable Yosemite debug (25 more machines)
    • Enable Yosemite on mozilla-aurora (15 more machines)
We currently have 14 machines left on Mountain Lion for mozilla-beta and mozilla-release branches.

As a I mentioned earlier, the two constraints with this project were to use the existing hardware pool that constantly runs tests in production and keep the existing wait times sane.  We encountered two major problems that impeded that goal:

It's a compliment when people say things like "I didn't realize that you updated a platform" because it means the upgrade did not cause large scale fires for all to see.  So it was a nice to hear that from one of my colleagues this week.

Thanks to philor, RyanVM and jmaher for opening bugs with respect to failing tests and greening them up.  Thanks to coop for many code reviews. Thanks dividehex for reimaging all the machines in batches and to arr for her valiant attempts to source new-to-us minis!

References
1Wait times represent the time from when a job is added to the scheduler database until it actually starts running. We usually try to keep this to under 15 minutes but this really varies on how many machines we have in the pool.
2We run tests for our products on a matrix of operating systems and operating system versions. The terminology for operating system x version in many release engineering shops is a platform.  To add to this, the list of platform we support varies across branches.  For instance, if we're going to deprecate a platform, we'll let this change ride the trains to release.

Further reading
Bug 1121175: [Tracking] Fix failing tests on Mac OSX 10.10 
Bug 1121199: Green up 10.10 tests currently failing on try 
Bug 1126493: rollout 10.10 tests in a way that doesn't impact wait times
Bug 1144206: investigate what is causing frequent talos failures on 10.10
Bug 1125998: Debug tests initially took 1.5-2x longer to complete on Yosemite


Why don't you just run these tests in the cloud?
  1. The Apple EULA severely restricts virtualization on Mac hardware. 
  2. I don't know of any major cloud vendors that offer the Mac as a platform.  Those that claim they do are actually renting racks of Macs on a dedicated per host basis.  This does not have the inherent scaling and associated cost saving of cloud computing.  In addition, the APIs to manage the machines at scale aren't there.
  3. We manage ~350 Mac minis.  We have more experience scaling Apple hardware than many vendors. Not many places run CI at Mozilla scale :-) Hopefully this will change and we'll be able to scale testing on Mac products like we do for Android and Linux in a cloud.

by Kim Moir (noreply@blogger.com) at March 20, 2015 06:52 PM

JBoss Developer Studio 8.1.0.CR1 and JBoss Tools 4.2.3.CR1

by akazakov at March 20, 2015 06:03 PM

We would like to announce Red Hat JBoss Developer Studio 8.1.0 CR1 and JBoss Tools 4.2.3 CR1 is now available.

jbosstools jbdevstudio blog header

Installation

Red Hat JBoss Developer Studio comes with everything pre-bundled in its installer. Simply download it and install it like this:

java -jar jboss-devstudio-{version}-installer-{standalone|eap}.jar

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

This release requires at least Eclipse 4.4 (Luna) but we recommend using the Eclipse Luna SR2 Java EE Bundle since then you get most of the dependencies preinstalled with Java EE Bundle and SR2 release includes some critical fixes.

Once you have installed or if you have JBoss Tools 4.2.x already installed, you can use our update site directly for JBoss Tools:

http://download.jboss.org/jbosstools/updates/development/luna/

And for JBoss Developer Studio Bring-Your-Own-Eclipse:

https://devstudio.redhat.com/updates/8.0-development/

Note: JBoss Tools 4.2.3 and JBoss Developer Studio 8.1.0 will become available in Marketplace only for Final releases at early April

What is New?

We are getting close to the final release. So, we focused on bug fixing in this release.

Upgraded Forge 2 Runtime

Besides bug fixes, the Forge 2 runtime was upgraded to 2.15.1.Final. See the release notes here.

There is also an improvement in Forge wizards which now render notes below the inputs (where available):

note

It’s worth mentioning that the Forge 2.15.1 release has an annoying bug which prevents addons creation. The upcoming JBoss Developer Studio 8.1.0.Final will include the fixed Forge 2.15.2.Final (has been released today).

What is Next?

The next stop is JBoss Tools 4.2.3.Final and JBoss Developer Studio 8.1.0.Final which are going to be released in two weeks.

Enjoy!

Alexey Kazakov


by akazakov at March 20, 2015 06:03 PM