This Is Not Your Father's House!

To continue the "Not your father's" series (see Sven's blog and Marcel's blog) you can imagine that if even Java and IDEs have evolved over the years, the way that people want to use and operate their houses has tremendously changed as well!

As many EclipseCon attendees are likely to spend more time with their IDE and Java than with their families at home, they might find the idea appealing to also use Eclipse technologies for remotely adjusting the heating, turning off the lights, checking if the latest internet shopping has arrived or telling their spouses "I love you" through XMPP and text-to-speech, while staying late in the office another time ;-)

So if you are a geek and are interested in hardware, do not miss my talk at EclipseCon Europe this Thursday, 11.30am. I am going to demonstrate you how easy it is to add new hardware devices to your home automation infrastructure as well - luckily a few sensors are spread out over the conference venue.

You have not heard about the M2M contest at EclipseCon Europe yet? Go and prepare yourself for your participation then! And no worries - I won't compete with you in the programming contest as I will be a member of the jury :-) Looking forward to your submissions!

Using Xbase for Home Automation Rules

Up to now openHAB has embedded JBoss Drools as a rule engine for automation rules. Although Drools is very powerful, this solution also has a few problems: The Drools IDE is not completely working in the openHAB Designer, so that no code completion and syntax checks are available for the rules. This makes the creation and debugging unnecessarily difficult, especially as the Java syntax of the rules is not very intuitive.

Although Drools offers an option to define tailored DSLs for rules, which could lower the syntax complexity, I personally feel that Xbase might be a better match for openHAB on the long run. This is why I have started with the development of an alternative rule engine for openHAB, which is fully based on Xbase. I would like to give you a brief summary of what exactly I have in mind:

Being a part of Xtext, Xbase perfectly integrates with the item and sitemap definitions of openHAB (which are already based on Xtext). It will therefore be easy to reference items from within rules and to have full IDE support on them. The "execution" part of a rule would be basically an list of Xbase expressions, which leaves a lot of power to the user as he can do all actions he was able to do in a Java-syntax Drools rule.

The main challenge is the "when" part of a rule, i.e. the triggering condition. Here lies the full power of Drools: Using a sophisticated RETE-algorithm it is possible to have relations between rules, where the triggering of one rule means the deactivation of others etc. This is indeed very powerful and necessary for expert systems and alike. For home automation use, my impression is that this rather confuses the normal user who still wants to be clear on what is executed when (and hence the defined rules usually use quite simple trigger statements).

The idea is to provide different kind of triggers (of different categories) for the new engine:

• Event-related triggers: "Item X was updated", "Item X changed to OFF" or "Item X received command UP"
• State-related triggers: "State X == ON", "State X != 0" or "State X > 20"
• System-related triggers: "System has started" or "System is shutting down"
• Timer-related triggers: "Time is midnight" or "Timer cron(0 * * * *)"

Obviously, one can think of many other trigger possibilities, but the list above should imho do for a start. Keep in mind that you can still do additional if-statements inside the "execution" part of your rule if these triggers do not suffice.

An example rule could hence look like this:

rule "Announce caller"

    when

        Item IncomingCall was updated,

        State Presence == ON

    then
        send MusicPlayer OFF

        say IncomingCall.newState + " is calling";
end

If you compare this example to the current Drools syntax you will see that it is much more natural to read. Having full IDE support with code completion etc. also makes writing such rules much simpler than it is today.

I am planning to show this new rule engine in action in my talk at EclipseCon Europe on November 3 in Ludwigsburg, so make sure you are there if you are interested in it!

Building p2-enabled products with Tycho

Working on the build and the packaging of openHAB, I had to undergo quite some efforts to get it done with Maven3/Tycho.

My special challenge was to package a product which is p2-enabled and includes root files. If you just want to do the one or the other, it works quite straight forward: You can use the "eclipse-application" Tycho packaging type to build Eclipse RCP products, which will also nicely include any root files that you have defined on your features.

Since version 0.10.0, Tycho also supports building p2-enabled products (TYCHO-188), but you will have to use the "eclipse-repository" packaging type to do so. Unfortunately, root file inclusion does not work with this packaging type (due to very complex reasons, see TYCHO-513 and TYCHO-465).

So what is the workaround to have both at the same time? I have chosen a combination of the "eclipse-repository" packaging and the "classic" Maven assembly plugin to do this job.

The "eclipse-repository" packaging is used in a Maven project that contains the RCP product definition. Using the "materialize-products" and "archive-products execution, makes sure that the p2 director is used to install and package a product from the repository (for all platforms that are listed in the configuration of the target-platform-configuration Maven plugin). Note that choosing Mac as a platform does not seem to be an option right now, at least I could not get it working...

If you now run a "mvn clean install" on this project, you will find the resulting zip files in the target folder. But how to add additional files (such as readmes, licenses, start scripts, additional libraries and folders, etc.) to it to make it your final distribution? That's where the Maven assembly plugin comes into play:

You need to create a Maven project that contains the files you want to add. The assembly plugin allows the inclusion of project dependencies in the assembly, so we need to define a dependency on our product project in our pom.xml. The problem here is that if you do this as usual, you will end up with the packaged p2 repository to be included in your assembly as this is the primary artifact built by the "eclipse-repository" packaging. Luckily, the product zips are attached as additional artifacts to the build result, so we can define a dependency like:

<dependency>
  <groupId>com.acme</groupId>
  <artifactId>com.acme.rcp.product</artifactId>
  <version>${project.version}</version>
  <type>zip</type>
  <classifier>win32.win32.x86</classifier>
</dependency>

In the assembly descriptor, you then need to say that you want to unpack this dependency into your assembly. As Tycho often packages a bit to much into the zips, you can also take this opportunity to remove a few contents that you do not want in your final distribution:

<dependencySets>
  <dependencySet>
    <useStrictFiltering>true</useStrictFiltering>
    <useProjectArtifact>false</useProjectArtifact>
    <useTransitiveDependencies>false</useTransitiveDependencies>
    <outputDirectory>/</outputDirectory>
    <unpack>true</unpack>
    <unpackOptions>
      <excludes>
        <exclude>**/org.eclipse.platform.doc*.jar</exclude>
        <exclude>**/org.eclipse.jdt.doc*.jar</exclude>
      </excludes>
    </unpackOptions>      
    <includes>
      <include>*:org.openhab.designer.product:*:win32.win32.x86</include>
    </includes>
  </dependencySet>
</dependencySets>

Note the reference to include (only) the dependency to the zip for the Windows platform; this is necessary as you might have many dependencies for different platforms defined in your assembly pom.xml. This include tag makes sure that this assembly descriptor picks up the right dependency (you can have other assembly descriptors for other platforms in the same assembly project).

This solution might not be the most elegant, especially if you are building packages for many different platforms (you need a separate assembly descriptor for each). But it works for me and I thought it could be helpful to others as well. If anybody knows a smarter solution or has a suggestion how to improve mine, I'll be more than happy to listen :-)

Binary builds for openHAB available!

As promised during my talks at the Eclipse Summit Europe and the OSGi Users' Forum Germany, I have finally fully automated the build of openHAB with Maven3/Tycho and uploaded the result to the openHAB homepage.
You will find there a platform-independent runtime zip that should work out of the box on Windows, Linux and Mac. This is all you need to get started. If you prefer IDE support for the configuration and rule files, get the openHAB designer zip file as well.
Besides these components, there are also optional bundles available in the download section, which you can add to your runtime if required for your setup. For all of this, simply follow these simple installation instructions.
Please excuse that the documentation about the configuration files, formats and options is still very limited - please visit the discussion group if you are in any doubt of what you need to do. I'll take care to update the documentation on the website subsequently.

openHAB @ Eclipse DemoCamp in Darmstadt

I had the pleasure to present my openHAB project at the Eclipse Helios DemoCamp in Darmstadt on July 14, 2010. First of all, a big "thank you!" to Jochen Hiller and Marcel Bruch who have organized this great event and gave me the opportunity to do a short demo.

Altough most of my presentation was a live demo, I also had some slides that I have now made available on SlideShare for anyone who is interested.

Tycho Entering the Eclipse Space

Almost two years have passed since my blog post about the the discrepancy of OSGi/p2 on the one side and Maven on the other. At that time I was pessimistic that the two worlds would ever come together and the creation of the B3 project even reinforced that impression.

Nonetheless I followed Sonatypes efforts on the Tycho front during the last year, which looked very promising. It actually already works so well that I recently changed the build of openHAB from Maven2/PaxConstruct to Maven3/Tycho - it's really cool (a blog post with details will follow soon).

Seeing that Chris Aniszczyk has now also embraced Tycho for the JGit/EGit builds is a clear sign that Tycho (and thus Maven) is slowly being picked up in the Eclipse space.

And the best news: Tycho has just been proposed as an Eclipse project! As the proposal states, it "competes with these [Buckminster, B3, PDE Build and Athena] projects". But seeing its current stability, its ease-of-use and all its possible synergies with the existing Maven tooling, I am pretty sure that it will win the race for being the preferred future build infrastructure for Eclipse/OSGi projects.

Kudos to Sonatype, who really put a lot of effort into this and who has torn down the barriers between the two worlds!

Choosing a Versioning Control System

When initiating an Open Source project like openHAB, one of the many questions you have to answer before you start is: What VCS should I use?

In the beginning I did not really realize that this is an important question. Being a professional Java developer building commercial products with Eclipse, the use of Subversion with Subversive as an IDE integration just seemed natural to me and not worth any further considerations.

It was more by chance that I noticed questions about using git on other OS projects that were using SVN as well as the activities in the Eclipse community around (E)git. When Ekkehard Gentz started a blog series about DVCS and Eclipse, I eventually decided that I needed to have a closer look.

After having grasped the great advantages of a DVCS, especially for Open Source projects, I then had to decide for one - to keep things simply, I only looked at the most popular ones, Git and Mercurial.

As I am using OSGi and Eclipse, there were quite some strong arguments for Git:

• With JGit there is a pure Java implementation available
• EGit is now under the Eclipse umbrella and actively developed by many gifted Eclipse committers.
• It seems that Git is more hyped than Mercurial (at least that's my personal impression).
• Git seems to be more powerful and flexible

Hence I installed Git and EGit and gave it a try. After working with it a bit, I noticed that I didn't really feel comfortable with it. It is difficult to say why, but I made out the following reasons:

•  I am a Mac and Windows user and Git somehow made me feel that its home is Linux. Although there is now a Windows version with msysgit, cygwin used to be the official way of using Git on Windows.
• Coming from SVN, the Git vocabulary can be confusing - e.g. something like a svn revert is not done with git-revert, but with git-reset. Together with the abundance of commands and functionality of Git, this can easily make people feel lost if it's their first time with a distributed VCS.
• The standard way for pushing and polling with Git is ssh - but this makes things much more difficult to use, if you are behind a firewall.
• EGit is still an incubation project and there's still some way to go until it reaches a level like Subversive: There is no support for the "Team Synchronization" view, which I use a lot. It also had some trouble with deletion and renaming of files. Last but not least - it is lacking icons on the context menus. Ha, I know, this is only cosmetics and should not be relevant at all; but still it leaves the impression of being a version to early to be used.

Almost all of the above items felt better on Mercurial (and HgEclipse), so I finally decided to go for it. I guess on the long run, I might reconsider this, once EGit has matured, but for the time being I am happy with this situation. And it is very reassuring that there are plenty of tools around to convert a Mercurial repo into a Git repo and vice versa - so no decision needs to be taken for eternity!

Now I am only waiting for Ekke to finish his series to eventually see to what conclusion he came and which DVCS is the one of his choice :-)