Yearly Archives: 2015

28 posts

Testing Diaspora – Part 3

diasporaThis is the third time I am testing Diaspora. I never wrote about the other attempts, but between Christmas and New Year a had a bit of time writing this together.

Motivated by the article at Heise about diaspora, I decided it is time to give diaspora another try. I did try the first version after the crowdfunding campaign and one or two years later.

For this test is registered at “” right here:

The first thing I have to say is that it still is a problem to start right away. There are a lot of pods (diaspora servers) running, where you can easily create a new account right away. But then … I did register an account at a few years back. Just to find out now that this pod runs on a pretty old version of diaspora and does not accept any new registrations. It looks kind of dead to me. Now I have my account on a pod, I can download my account data. But I cannot migrate my account to a new pod. I have to start from scratch and lost all my social activity. Not that I did much with that account ;-)

So in the end you somehow want to be in control over your pod. And having a diaspora ID which contains your own domain name is just another reason for that. But setting up diaspora is a nightmare. Looking at the different ways, you do need a full virtual server or pay at least $15 each month for running your own cloud instance at some cloud provider when using the Bitnami variant of diaspora. Bitnami again has changed diaspora in some ways, so that diaspora themself ask you to look into the Bitnami wiki first. A few other cloud based approaches ask you to fork and edit the diaspora git repository for a start.

I wouldn’t mind paying a few bucks for hosting my own pod, but paying for a full blowing virtual server and setting up things like redis for one or two accounts on this hud is just oversized.

Joining a pre-existing pod on the other hand, seems like a bad idea, unless you really know who is running the pod. In the end you trust your social account and data to somebody you either don’t know and are not sure that they will keep the pod (and thus your social identity) running as long as you like it.

Of course the same is true for Facebook, Google+ and all the others. But diaspora wants to make a change. So setting up a pod or getting an account that you really control must get simpler!

As it looks to me, right now the diaspora software itself targets installations for a bigger number of users. So each pod should by capable of running as many accounts as possible (although diaspora itself is decentralized). And it really is good that there is a protocol between pods which can be implemented in a different way. So there are implementations of the diaspora protocol which are not based on the diaspora source code itself.

But back to the problem of running a pod that you control. Either there is a “light version” of a pod, which supports a few users instead of a thousand, then sharing a virtual server would be much easier. A docker container, an OpenShift instance, some micro instance on Google Cloud or AWS. That would be much cheaper.

At the same time this would allow one to run diaspora in a Raspberry Pi like device at home. If you are only hosting one or two accounts, your local DSL line is pretty much sufficient for running your own pod.

As sad as it is, I guess this means seeing you all for part #4 in a few years. If you have some spare time, I think contributing to diaspora is a great idea, because the idea behind diaspora is great. But right now, it simply is not my cup of tea.

Christmas presents – sell/recycle for charity

Before and on Christmas most people think about people in need, and hopefully donate something. Not necessarily money, but presents as well.

But after Christmas there are lots of unwanted presents and things you don’t need, don’t like or will ever use. In most cases these items end up in the trash, at some shelf or, at best, being returned to the store.

Now just think of a different way. If you could just put those presents up at E-Bay, in a charity special. You start an auction, put up your unwanted presents and select some registered non-profit organization that will received the money. E-bay won’t charge you for the transaction, at least for those charity auctions.

Sounds like a great idea to me.

Test driving “Mattermost” at the Eclipse Foundation

Mattermost Logo Thanks to @bruncedric and the Eclipse Webmasters we were able to quickly start a test of Mattermost at

“Mattermost” is a Slack/HipChat/… like web messaging system (aka webchat). I don’t want to go into too much detail of the system itself, but the main idea is to have a “faster-than-email” communication form for a team of people. Comparable to IRC, but more HTML5-ish. It also features a REST API, which can be used to automate inbound and outbound messages to the different channels.

Why not Slack or HipChat? Simply because the Eclipse Foundation requires its IT components to be based on open source solutions and not rely on any service which can go away at any moment, without the possibility to rescue your data in a portable format. Which is quite a good approach if you ask me. Just imaging you have years of data and loose it due to fact that your service provider simply shuts down.

So right now there is a Mattermost instance at which is intended to be a setup for testing “Mattermost” and figuring out how it can be used to give Eclipse projects a benefit. Simply adding more technical gimmicks might not always be a good idea.

Also does Package Drone have a channel at mattermost.

So go ahead and give it a test run …

… if you have troubles or ideas … just look at eclipse/mattermost.

Parsing RPMs in Java

RPMThe core idea of Package Drone is to extract meta data from files and generated some sort of repository index. And although Package Drone’s main focus is on OSGi, we did want to implement a YUM repository adapter and for this we needed to extract metadata from RPM files.

Package Drone itself is written in Java. So I wanted some sort of Java approach. Of course it would be possible to run the rpm command in the background, parse the output somehow and gather the meta data information from that. Or make a JNI wrapper to librpm and extract the information with a native library call. However this is not only prone to error, but also a nightmare when it comes to porting.

So I really was looking for a plain Java solution, which also was compatible with the license of Eclipse (EPL). I came across jRPM and redline.

jRPM was last updated around 2005, still has an Apache 1.1 license and simply stuck in the past. redline is more up to date and sounded promising at first, but then the library is really more like a jar file with some “main” entry points and an ant task. There is no clear API for programmatically reading the RPM files. And the legal aspect was a little bit troublesome to me. 28 contributors according to GitHub, no CLA, an “MIT license” from a company simple named “FreeCompany” and the Google Tracking code backed right into the Maven POM file. So, I had to do it myself ;-)

A fresh start

So not to fall into the same pitfalls, I did start to write a parsing library first, instead of directly writing the Package Drone extractor module. This way there is now a clean library which can parse RPM files. It also is an OSGi bundle, which was necessary for Package Drone, but does not make use of any OSGi functionality. So it still can be used as a simple JAR file. Licensed under the EPL, as requirement for Eclipse projects anyway and the Eclipse CLA and IP process to take care of the legal aspects. And if you are an Eclipse project, you even don’t need a CQ to use it.

What’s the catch?

I did implement what I needed. And that was reading RPM metadata and building a YUM repository index. So writing RPM files or reading/writing signatures is not possible at the moment. However there are plans to sign YUM repositories and RPM files as well. So this limitation is only a matter of time. Also are there some fields which are not mapped to enums. RPM used numeric IDs internally, many are mapped, but not all. You can still access those, but by number not by enum in that case.

Also is this library currently not on maven central. But again, I am also working an a “deploy to Maven Central” feature in Package Drone, which will clear that blocker.

So where are we now?

So the code is right here on GitHub. In a few weeks we will have a binary download, but right now the Eclipse IP process has to clear the way first.

Looking at the source code of the test case you can see how this library works. Instead of working on a plain File, it can work on an InputStream, which can be important if your RPM file comes from a remote location.

The following example shows how to extract metadata and content from an RPM file.

[code language=”java”]
try(RpmInputStream in = new RpmInputStream(new FileInputStream("file.rpm"))) {
String name = (String)in.getPayloadHeader ().getTag (RpmTag.NAME);

CpioArchiveInputStream cpio = in.getCpioStream ();
CpioArchiveEntry entry;
while ((entry = cpio.getNextCPIOEntry ()) != null) {
process ( entry );

There is also the older JavaDoc, which has to be updated to reflect the change to org.eclipse.packagedrone.

What’s next?

Of course a binary release at Eclipse, an updated JavaDoc and publishing the binaries to Maven Central. Beside extending the library to be able to sign and write RPM files.

If you like to help or need some help using it, just let me know!

The ConPanion

While preparing for EclipseCon Europe 2015 (a few weeks back I have to say, it was a great conference) I again wanted to a have a small mobile helper. So instead of forgetting (again) about it, this time I briefly wrote it down. So here it is.

Going to a conference I do want to have the schedule in advance, I want a nicely rendered view on my mobile phone, offline(!), making plans which talks to attend while riding public transportation. Clicking together a plan. Now for this to work, the conference itself has to provide some sort of data set to make this happen. I really don’t want to have a specific mobile app for each conference. Also adding all the features I do have in mind would crash all budgets which might be available for a single conference. No, the basic idea is to make one tool and let the conference publish the information itself. So the tool simply picks up this … let’s say, XML file, containing all the information necessary for the mobile helper (ok, use JSON if you like that better).

So the effort for the user is to download the app (once) and the conference simply has to provide (and update) an XML file. This is “Tier 1” or the “Free Tier”.

Now we do have two additional tiers (groups of services) which could be used to bring in money, but in any way they will cost money for hosting.

The first group of extensions is some sort of default, additional services around the conference. Like ad-hoc meetings for example. Type a hashtag and create a new ad-hoc meeting and gather a interested persons to have a chat (an easier version of EclipseCon’s BoFs). This requires some backend service, to money has to be spent and in the other way round it has to be earned. Of course it would also be possible to offer car rentals, hotel reservations etc.

The second group of extensions to the app would be the service to host the content for the conventions. Not all conventions are softare developer conferences (at least I heard that), so maybe the conference does not want to fiddle around with the XML data set itself, but have a beautifully designed web UI which does all the magic.

I did write up the ideas in a PDF file, but don’t expect too much additional information. This is the basic idea.

Read the PDF: ConPanion.pdf

You left your phone!

Dear Google,

Today it happened again. I left my mobile phone at home. I realized that before entering the train, so I went back, grabbed it and went back to catch the next train. This gave me a few minutes to think about that ;-)

You got Android Wear/Watch and already have the smart unlock functionality where your watch (if it is near your phone) can unlock it.

Now you also could detect the opposite scenario, my watch detects it lost the “visibility” of the my mobile phone, so an alarm could pop up on my watch, notifying me about the fact that it left my phone. I can dismiss the alarm, and decide if I go back.

This might cause a few false alarms, but with a small set of additional rules (like “only do this at home/work”, only do this around 8 am and 6 pm) these could be reduced quite a bit.

Please let me know when you are ready.

Kind regards


PS: Actually I do need to buy a watch for that …

Java 8 streaming – or not?

One of the most advertised use cases of the new lambdas in Java 8 is the possibility to stream collections and transform it. The “series of tubes” has a lot of examples on how to do this, I just wanted to look at it from a different perspective, readability.

So starting with a real-life problem of a map Map<ResultKey, List> result which I want to transform into a Set<String>.

Before Java 8, I had something like:

[code language=”java”]
Set<String> ids = new HashSet<> ();
for ( List<ResultEntry> list : result.values () ) {
for ( ResultEntry entry : list ) {
if ( entry.getAction () == Action.DELETE ) {
String id = entry.getArtifact ().getId ();
ids.add ( id );

Now, with Java 8, I can do:

[code language=”java”]
Set<String> deleteSet = result.values ().stream ()
.flatMap ( list -> () )
.filter ( entry -> entry.getAction () == Action.DELETE )
.map ( entry -> entry.getArtifact ().getId () )
.collect ( Collectors.toSet () );
context.deleteArtifacts ( deleteSet );

Neither one is shorter nor seems less complex from an initial view. So, which one is better?

Searching for lyrics in Google Music

google music logoDear Google,

as a subscriber of Google Music I often search for music I listened to in the past. In many cases I do know the title, artist or sometime the name of the album.

But sometimes I just remember a fragment of the lyrics. However, searching for a fragment from the lyrics brings up nothing useful in Google Music.

So please Google, allow me to search not only for meta data like title, artist or album, but also for lyrics.

And while you are at it, please also let me limit the search afterwards, like a time period (the 90s), a genre (Rock), a language (some German bands do use English album title, but produce German lyrics), a country of origin (yes, German bands are capable of singing English lyrics).

You are the search giant … aren’t you?

Calling from Google search

Dear Google …

Bildschirmfoto 2015-08-15 um 17.18.49

… I just did a search for some business an Google and actually the first hit and the suggestion box on the right side is the perfect match for what I was looking for. The info box contains all the relevant information, including the phone number, which is a clickable link.

Now I did the search on the desktop computer and not on my mobile phone. Clicking the link automatically starts Google Hangout with a call to that telephone number, without asking for confirmation. Too bad that the computer does not have a microphone attached.

So please…

… instead of dialing from my desktop computer, with Hangout, I would rather want to see a small confirmation box, which (once pressed “OK” or “Yes” or whatever) sends a message to my mobile phone, triggering the call to this telephone number.

Since I was already logged in with my Google Account when doing the search, there should be no problem detecting my Google registered Android phone, and sending a Google Cloud 2 Device Message which triggers the call. You can do the same using “Chrome to Phone” for web pages.

Hopefully you can add this in a future release ;-)

Maven Tycho/JGit based build timestamps and the “target” directory

Now when you build OSGi bundles using Maven Tycho, you probably ran into the issue of creating a meaningful version qualifier (remember, an OSGi versions always is major.minor.micro.qualifier, so no dash and definitely no -SNAPSHOT).

There are a few approaches ranging from fully manual assignment of the build qualifier, simple timestamps and timestamps based on the last Git change.

The background

The latter one is described in the “Reproducible Version Qualifiers” wiki page of Tycho as a recipe to create the same qualifier from the same source code revision.

Actually the idea is pretty simple, so instead of the current timestamp, the last relevant change in the git repository, for the directory of the bundle, is located and then used to generate the timestamp based qualifier.

As a side note: Personally I came to the conclusion, that this sounds great in the beginning, but turns out to be troublesome later. First if all, the Build Qualifier plugin conflicts with the Source Ref Plugin, which generates a different manifest. Both plugins find different last commits and therefore a different MANIFEST.MF gets generated. So two builds produce two bundles, with the same qualifier, but actually (due to the MANIFEST.MF) different content, with two different checksums, which causes issues later on and has to be cleaned up by some baseline repository matching. In addition you simple cannot guarantee that two different builds come to the same result. Too many components (actually Maven and the local host) are outside of the source code repository and still influence the output of the build. But this post is about the JGit based timestamps ;-)

A simple configuration using the Git based approach looks like this in the parent pom file:
[code language=”xml”]

As you can see, there is a configuration property jgit.ignore which allows to exclude a set of files in the search of the last relevant commit. So git changes, which are only changing files which are ignored, are also ignored in this search for the last modification timestamp. Since the pom.xml will probably just get changed to point to a different parent POM, this seems like a good idea.

The problem

Now what does happen happen, when there are uncommitted changes in the working tree? Then it would not be possible for the build to determine the last relevant commit, since the change is not committed! Maven Tycho does provide a way to handle this (aka “Dirty working tree behaviour”) and will allow you to ignore this. Which might not be a good idea after all. The default behavior is to simply error and fail the build.

For me it became a real annoyance when it complained about the “target” directory itself. The truth is, this output directory should be added to the “.gitignore” file anyway, which would then also be respected by the git based build timestamp provider. But then again it should not fail the build just because of that.


But the solution to that was rather trivial. The jgit.ignore property follows the git ignore syntax and also allows to specify directories:

[code language=”xml”]

There are two things which have to be kept in mind: each entry goes to a new line, the root of the evaluation seems no the be the root of the project, so using “/target/” (compared to “target/“) does not work.