Technical Stuff

88 posts

Assorted technical stuff of all kind.

Package Drone 0.0.6

Here is another release of Package Drone – 0.0.6!

Be sure to check out the most recent release on github.

The main changes are:

  • Add automated tests using Selenium WebDriver
  • Create a build system using Maven Tycho
  • Create start scripts for SystemD and Upstart
  • Create .deb and .rpm packages for Ubuntu 14.04 (Mint 17) and CentOS 7 (RHEL 7).
  • Provide APT and YUM repositories at

So this release was more about build, stability and ease of installation. That is why there are also no screenshots this time ;-)

Package Drone 0.0.5

I am happy to announce yet another version of Package Drone – 0.0.5.

Be sure to check out the most recent release on github.

The main changes are:

  • Switch from Pure CSS to Bootstrap
  • Clean up the UI
  • Add channel level meta data and channel aggregators

Also a few bugs where fixed. Sadly in 0.0.4 there was a bug which prevented the schema creation to fail. This one is fixed in the 0.0.5 release.


Package Drone 0.0.4

I am happy to announce that package drone 0.0.4 is released.

Be sure to check out the most recent release.

The new features are:

  • Support for OSGi R5 XML repository index
  • Create Eclipse source bundles from Maven source attachments
  • Manage database structure from within package drone (nor more command line SQL)

See the full release information at github.

Especially the OSGi R5 repository support allows a few more use cases, like letting Bndtools consume artifacts from a P2 build, PDE or Tycho.

Eclipse theme after Linux Mint Upgrade

A while ago I wrote about a theming issue with Linux Mint and Eclipse. It took a while longer than expected, but the change finally made it into Linux Mint in version 17.1.

However, starting with Linux Mint 17, there seems to be a new issue. Not that dramatic like the old one, but still somewhat annoying. The default Linux Mint theme (Mint-X) chooses a light gray base color value as a background. This might look nice in most applications, however the mixture of Eclipses (E4) recent approach to create its own theming over the operating system, somewhat collides with that.

Text editors and the tree view inherit a light gray background from the operating system theme, while other Eclipse background elements stay white.

There seems to be a simple fix for that however. Edit the file /usr/share/themes/Mint-X/gtk-2.0/gtkrc and change the first real line from:

[code]gtk_color_scheme = "bg_color:#d6d6d6\nselected_bg_color:#9ab87c\nbase_color:#F7F7F7" # Background, base.[/code]


[code]gtk_color_scheme = "bg_color:#d6d6d6\nselected_bg_color:#9ab87c\nbase_color:#FFFFFF" # Background, base.[/code]

However, and that is why I stumbled over this after the upgrade to Mint 17.1, this change will be overridden after an upgrade of the theme package. This never happened one in version 17, but you never know.

Note: It is also interesting that Eclipse/SWT seems to use GTK 2 instead of GTK 3. If you have some information in that, please drop me a line!

Package Drone 0.0.3

There is a new version of package drone – 0.0.3!

See the release notes on github for Version 0.0.3

Beside a lot new features, which are described in the release notes, the two most interesting topics are:

Two working workflows

Now depending on the channel configuration it is now possible to run channels either for Maven Tycho or by manually uploading artifacts. The output always can be consumed as P2 repository.

With Maven Tycho the P2 metadata created by Tycho gets uploaded and used by the P2 adapter to create the P2 repository data.

In plain OSGi mode Package Drone extracts the dependency information directly from the uploaded artifacts and uses it in order to create virtual P2 meta data file. In both cases the P2 adapter uses the same way to construct the final repository.

For the plain OSGi mode it is also possible to create a generated P2 feature artifact. For this a new instance of a generated P2 feature is created, the meta data like Feature ID, version, etc are manually provided, and package drone will add all bundles in the channel to the feature automatically, so that there always is a feature available for plain OSGi bundles.

The plain OSGi mode is extremely interesting if you need to consume OSGi bundles which are hosted on Maven Central, but have no P2 repository available.

Which hopefully will also be one of the next features in package drone, a replicated artifacts, from Maven Central (or any other Maven 2 repository).

The replacement of spring

I started with Spring WebMVC in order to have an easy start. The idea always was to have a OSGi style, modular application. And Spring simply can provide the base for that. While Spring might be a nice framework for monolithic web applications, it simply is not modular enough for OSGi. Yes, you head right, Spring is not modular enough. First of all, Spring cannot be brought into the OSGi environment, working between bundles. Having one bundle with all and everything inside is ok. But splitting it up seems impossible.

In the past there was Spring Dynamic Modules (Spring DM), which changed to Eclipse Virgo now. However Spring DM is dead and Eclipse Virgo seems only provides part of what you need, and almost nothing when it comes to the web.

So the solution was to write a small web dispatching layer, use the idea of Spring’s @Controller mechanism and use real OSGi. Controllers now get registered as OSGi service, once they have all their dependencies met. A central dispatcher servlet provides access to all controllers, no matter which bundle registers them. Once the service is gone, the controller is removed. By having real dynamic services it is easily possible to add new functionality, menu entries, resources during runtime, running in the same web context. Install and update plugins, perform a simple setup, things that every PHP web application can do.

Of course the downside is, that part of Spring’s functionality gets replicated, but it simply was to much trouble to split off parts of Spring WebMVC.