Monday, 30 Nov 2009 16:22:43 +0100

For a number of reasons, I’ve recently set up a new OpenPGP key, and
will be transitioning away from my old one.

The old key will continue to be valid for some time, but i prefer all
future correspondence to come to the new one. I would also like this
new key to be re-integrated into the web of trust. This message is
signed by both keys to certify the transition.

the old key was:

pub 1024D/88438F59 2001-09-06
Key fingerprint = 686E A9ED 7924 D8AE 9C0F A437 1FF8 4BD0 8843 8F59

And the new key is:

pub 2048R/6CD1AFCE 2009-11-30
Key fingerprint = 7D2B 1953 0509 DF80 B580 995E F4B6 EA16 6CD1 AFCE

To fetch the full key, you can get it with:

wget -q -O- http://www.kuppe.org/Markus-Alexander-Kuppe-0×6CD1AFCE-pub.asc | gpg –import -

Or, to fetch my new key from a public key server, you can simply do:

gpg –keyserver pgp.mit.edu –recv-key 6CD1AFCE

If you already know my old key, you can now verify that the new key is
signed by the old one:

gpg –check-sigs 6CD1AFCE

If you don’t already know my old key, or you just want to be double
extra paranoid, you can check the fingerprint against the one above:

gpg –fingerprint 6CD1AFCE

If you are satisfied that you’ve got the right key, and the UIDs match
what you expect, I’d appreciate it if you would sign my key:

gpg –sign-key 6CD1AFCE

Lastly, if you could upload these signatures, i would appreciate it.
You can either send me an e-mail with the new signatures (if you have
a functional MTA on your system):

gpg –armor –export 6CD1AFCE | mail -s ‘OpenPGP Signatures’ markus@kuppe.org

Or you can just upload the signatures to a public keyserver directly:

gpg –keyserver pgp.mit.edu –send-key 6CD1AFCE

Please let me know if there is any trouble, and sorry for the
inconvenience.

Regards,
Markus Alexander Kuppe

Signed version of this file can be found at http://www.kuppe.org/KeyTransitionTo6CD1AFCE.txt

Following up on our presentations given at EclipseCon earlier this year [1][2], I will do a talk on ECF’s implementation of distributed OSGi/RFC119 later today at the local Galileo DemoCamp here in Hamburg.
Make sure to show up in case you are in the area. Not just to hear about RFC119, but also to attend the other talks and the stammtisch afterwards. :-)

[1] Best Practices with distributed OSGi services
[2] Distributed OSGi – The ECF way

Git appears to gain a lot momentum as the DVCS for Eclipse recently. Even our benevolent dictator Mike M. deemed it important enough to comment on _the_ Git bug. ;-)
While I am a strong supporter of Git myself (mostly because I lack experience with Mercurial, bzr, Darcs), we should take a second before we make a decision. Simply because it looks like other (FOSS) Java-related projects are rather walking into the direction of Mercurial with OpenJDK, NetBeans being the most prominent ones (OK maybe just projects backed by SUN). On top of that Eclipse based Mercurial tooling is allegedly superior to Git in its current state (though this is probably going to change the second we pick a winner). From the feature set, both systems don’t seem to differ much (what I read however is, it might not be possible to rewrite history in Mercurial)

So in case you have a Mercurial/bzr/Darcs/… success story sitting in your pocket or you can answer Mike’s question regarding Mercurial, please leave a comment on bug #249745.

Oh yeah, with distributed version control being the hot topic for this year’s board elections, I am one of the candidates who had DVCS on his mission statement right from the get go. ;-)

Non-established since 2001

Many of us have probably written their PDE build around the famous build automation article. With Galiloe’s must do to provide p2 metadata, many projects are forced to update their build now.
We at ECF want to stick to our classic update site and keep build changes minimal though. So here’s how we’ve done our integration. Technically, it simply creates p2 metadata from pre build classic update site. You could also move generation out of PDE build if required.

//customBuild.xml
<target name="postBuild">
<ant antfile="${buildDirectory}/site/build.xml" target="updateSiteExport"/>
</target>

And just before everything is zipped in site/build.xml, let p2 generate metadata from bits at ${updateSiteStagingLocation} and you’re done.

//site/build.xml
<property name="updateSiteStagingLocation" value="${buildDirectory}/tmp/updateSite" />
<target name="updateSiteExport">
// build classic update site
...

// zip update site
...
</target>


Until the fix to bug #263449 hits the grounds, “inplace” has to be used instead of “updateSite”.

Yesterday the GSoC team gave the green light to Google summer of code 2009. Yay :-)
In case you don’t know what GSoC is all about, you should read the program faq or join us in #eclipse-soc at irc.freenode.net.

To the rest of us, lets not waste time but start to collect ideas and approach prospective students now! I’ve prepared a 2009er ideas page on the wiki for us to use.

With a bunch of breaking API changes ahead of me and no intention to get into CVS merge hell (using my own branch for the changes), I decided to give git a test spin. Others have blogged about it already and it appears as if the foundation is looking into the issue already but have postponed a decision until next year.
So I did like Andy has done before me and created a git mirror of ECF’s CVS with git-cvsimport. I’ll report back in a while how things work out with Egit (soon at Eclipse.org) and git <> CVS.
If people are interested to use the git repo, we’d need to figure a way to make the master available at ecf2.osuosl.org.

Jan S. Rellermeyer, Markus Kuppe, Scott Lewis
The Eclipse Communication Framework has released its version 2.0 with Eclipse Ganymede. Two of the new and noteworthy features that ECF is bringing to the mainstream Eclipse developer are service discovery and distributed OSGi services. In this talk, we will introduce the various tools and concepts that ECF provides the users with. Different service discovery protocols like SLP and mDNS are available for finding remote services in the network. The interaction with remote services is supported through distributed shared objects or the R-OSGi system. On top, applications can either access remote services completely transparently, or take advantage of an explicit API that allows advanced interaction patterns like asynchronous calls or futures. We will compare the ECF API with other related concepts and the ongoing efforts in the OSGi Alliance on RFC 119.

I’m currently working from Versant’s US office for one month. To save some time I brought a notebook over from Germany. Apparently a Dell notebook isn’t up to my typing, because the return key popped off and now the keyboard needs replacement. Unfortunately Dell _international_ support isn’t able to replace German keyboards (to be fair they can, it just takes them 6-8 weeks) and the German Dell support cannot ship replacement parts outside Europe. Even with a Business support agreement. So my only option is to replace the keyboard with an English one. But then typing on an English one with a German key mapping pretty much sucks. US keyboards miss several (important) keys. That’s why I’m currently switching to US key mapping. Lets see how long it takes me to be productive again with 10 finger.
Luckily my personal notebook is a Thinkpad. In more than four years it has never needed repair. And I’m a heavy user. Guess which brand I’ll buy next time when I get a new one? ;-)

Jan Rellermeyer and I are going to present ECF at the OSGi community event in Berlin. The talk is titled “Distributed OSGi Services with the Eclipse Communication Framework
(ECF)” and the abstract reads as follows:

The Eclipse Communication Framework will soon go into version 2.0,
which will bring the concepts around distributed OSGi services to the
mainstream Eclipse developers. In this talk, we will introduce the various
tools and concepts that ECF provides the users with. Different service
discovery protocols like SLP and mDNS are available for finding remote
services in the network. The interaction with remote services is supported
through distributed shared objects or the R-OSGi system. On top,
applications can either access remote services completely transparently, or
take advantage of an explicit API that allows advanced interaction patterns
like asynchronous calls or futures. We will compare the ECF API with other
related concepts and the ongoing efforts around RFC 119.

In case you’re in the area, make sure to attend. The speakers list includes the who is who of the OSGi community and I’m honored to be given the chance to present the work we’ve done in ECF. :-)