Developers, Developers, Developers! Maksim Sorokin IT Blog


Maven + Apache Felix: Easy Development and Debugging With Eclipse

This is a first post on in series about Maven + Apache Felix + CXF + DOSGi. Here we will combine Maven, Apache Felix and Eclipse. You have to use M2Eclipse plugin for this (or similar Maven-Eclipse integration plugin).

The problem:

  • Integrating Felix with Eclipse tutorial requires manual download and configuration of Felix distributable into workspace
  • Felix allows deploying only jar bundles, which is inappropriate for easy development and debugging

We can use the power of Maven and these two resources to solve both problems.

The idea about the first one is to


Maven + Apache Felix + CXF + DOSGi Series

This is a blog series on how to combine Maven + Apache Felix + CXF + DOSGi. The information presented may not be correct and some parts can definitely be improved. Not all posts are published immediately, so stay tuned!

Part 1 Maven + Apache Felix: Easy Development and Debugging With Eclipse
Part 2 Maven + Apache Felix: Best Practices
Part 3 Maven + Apache Felix + CXF: Creating a RESTful Webservice with CXF. A Simple String Example.
Part 4 Maven + Apache Felix + CXF: Creating a RESTful Webservice with CXF. Returning and Object.
Part 5 Maven + Apache Felix + CXF: Creating a RESTful Webservice with CXF. Consuming an Object
Part 6 CXF RESTful Webservices: Running on a Different Port
Part 7 Maven + Apache Felix + CXF: RESTful Webservice with CXF. Using POST.
Part 8 Maven + Apache Felix + CXF: Securing a Service with HTTP Basic Authentication
Part 9 Maven + Apache Felix: Strategy to Handle non-OSGi Dependencies
Part 10 Apache Felix: Running Two Instances of Felix Launcher in The Eclipse
Part 11 Maven + Apache Felix + CXF + DOSGi: An Example of DOSGi Service


Managing Properties Files: Awesome Eclipse Plugin

Resource Bundle Editor.

Eclipse update site:


IzPack Panels: Things You Have to Know When Developing Registry Panels

There are certain things one has to know when developing panels that interact with registry.

CheckedHelloPanel is an example of interaction with a registry. If you decide to go that way, you will need to do some additional things too besides writing the code.

First of all, you will need to define a COIOSHelper.dll in your install.xml:

<native type="3rdparty" name="COIOSHelper.dll" stage="both">
  <os family="windows"/>

The second thing is that if you take a look into CheckedHelloPanel code, you will see, that it also uses some code. You will need to include that into your panel jar too.
Here is the way how we do it. First, we took this and put it to our maven repository. For each our custom IzPack panel we have a separate maven module nesting some common parent routine (I have already described it in one of the previous posts. Then during package phase of our custom panel code we use Maven Shade Plugin to combine sources of and our panel code.

The third thing deals with development cycle. If you develop your own custom panel to work with registry using the way , you will need to place dlls inside "izpack" project.
Create src\native folder and copy dlls from bin\native directory in IzPack installation. Then you could use them inside install.xml:

<native type="3rdparty" name="COIOSHelper.dll" stage="both">
  <os family="windows"/>

This is because com.izforge.izpack.util.Librarian in IzPack has to know where to find the dlls. Since we import only the sources to Eclipse, dlls are not imported, so we have to do that manualy.


Manifest Version — with or without qualifier?

Should MANIFEST.MF contain qualifier or not? That depends on what strategy you use in your development cycle. When you change a plugin a lot during development cycle, it is better to add append a qualifier to the end of the version. In this case, everytime you will build a plugin, it will have a timestamp added to the end of the filename, for example:


If you will not have a qualifier, it will always be the same jar name:


In this case you may have some troubles. For example, when you run FeaturesAndBundlesPublisher with -append option. Since old and new bundle version have the same version (without added timestamp), old version will be preserved. In this case make sure to change the version of your MANIFEST.MF, when you make changes to the project without qualifier.


Running P2 Ant Tasks in Eclipse

If you have the following when executing p2 ant tasks in Eclipse:

Buildfile: C:\projects\p2\build.xml

C:\projects\p2\build.xml:6: Problem: failed to create task or type p2.mirror
Cause: The name is undefined.
Action: Check the spelling.
Action: Check that any custom tasks/types have been declared.
Action: Check that any <presetdef>/<macrodef> declarations have taken place.

Make sure that you run this task in the same JRE as workspace.

How to do that? Go to "Externals Tools Configuration". Choose your ant script. Go to "JRE" tab and select "Run in the same JRE as the workspace".

Tagged as: , , 1 Comment

Tycho “Profile id _SELF_ is not registered”

Are you using eclipse-application as a packaging type? Try eclipse-repository. Here is an example.

Tagged as: , Comments Off

Hints on Depending on Online P2 Repositories in the Target Platform

Depending on online P2 repositories in the target platform is not that bad, is it may look like. In Eclipse world there is no such thing as a released stuff. Everything is released when it is built. However, when a bundle is built with the same version, then it still has different timestamp.

Assume you have a target platform, in which you depend on a specific feature in online p2 repository of Helios. If you open file with a text editor, you will see something like the following:

<location includeAllPlatforms="false" includeMode="slicer"
    type="InstallableUnit"> <unit
            version="2.6.1.v20100914-1218" /> <repository
            location="" />

So even if a new release of "" with the same 2.6.1 version is done, it will have different timestamp! So no problems in that.

However, the problem is, that when you update the software site in your target platform in order to choose another dependency, it may update the version of previous feature to the newest one, which may break your build. The solution is to depend on different feature of the same p2 repository in different software update sites. So instead of:


In this case, when you will update the version of one feature, the other one will remain.

Of course, there is still a problem on depending on online p2 repositories since one day they may die. But you can mirror those on your servers and depend on mirrored ones, instead of untrusted remote ones.


Building with Tycho — Our Eclipse DemoCamp Presentation

Our Tycho presentation for Eclipse DemoCamp Copenhagen 2010.


Having Different Versions of the same Feature in p2 Repository

In one of the posts I talked about creating a p2 repository from plugins and features. In other one I showed how to make Tycho create a deployable feature. You can combine them both in order to have several versions of the same feature in p2 repository.

This works in the following way. First, you build a feature with Tycho. Then you merge it with existing p2 repository (it can also be used to create one) using p2 publisher, about which I talked in previous post. -append option ensures, that you add and not delete rewrite old ones.