Developers, Developers, Developers! Maksim Sorokin IT Blog


Maven + Apache Felix: Strategy to Handle non-OSGi Dependencies

This is another post in Maven + Apache Felix + CXF + DOSGi series.

Sometimes in the project plain Maven dependencies has to be used. A simple strategy to use those in OSGi project handled by Maven is to have a separate module, containing all non-OSGi dependencies and converting those to OSGi bundles using Apache Felix Maven Bundle Plugin.
So one may have the following structure of the project:


This nonOsgiDependencies projects would contain


Philosophy Differences between Eclipse and Maven in Dependency Management

Title of this post is a bit cumbersome. I want to discuss how Eclipse-OSGi world works with dependencies and compare it with Maven world.

In Eclipse-OSGi world dependencies usually are defined with a range. For example:

Require-Bundle: org.eclipse.ui,

Numbers in build number x.y.z are meant to be

  • x -- changes in API. Downstreamers should expect code breaking. Non-backwards compatible code.
  • y -- changes, which might lead to code breaking.
  • z -- bugfixes

Eclipse-OSGi world basically does not have understanding of "released" product. Built product is always "released" (if exposed to the public). Moreover, build number does not necessarily change. Thefore Eclipse-OSGi guys have problems, if they depend on online repositories. Because at any time new version of dependency with higher minor build number may appear and code may break.
What Eclipse-OSGi do then? Well, it is simple. They do not use online repositories! They used "frozen" version of those, for example by using standalone Eclipse installation as target platform. Usually this "frozen" target platform is being renewed at the beginning of each sprint.

Let's take a look on Eclipse-OSGi dependency management world from Maven perspective. Eclipse-OSGi world guys have SNAPSHOTs, but do not have releases. That is, you always grab the latest available version (of course, in possible range). Obviously, if we look from this perspective, it is very dangerous to depend on latest SNAPSHOT version.
In Maven world released products have to depend on released versions of dependencies. Moreover, when product is released, you are forced to change the build number. So there is no two releases with to numbers. Of course you can cheat and delete released product from maven repository and put another one, but at least you are guarded from doing that.

Ok, now why that matters. Lately more and more companies use Eclipse platform to build their products. And many development departments use maven heavily in the development process. Therefore they want to benefit from having maven to build Eclipse products. Tycho project allows to do that. However, beside many missing features in Tycho, there is a clashes between maven and Eclipse-OSGi world dependency ideology.

We already have some solutions and ideas to solve dependencies situation. However, let's wait with those until next posts..

Thanks to Tony Madsen for clarifications.


Dumping Maven Dependencies to Specific Folder

In order to dump all specified dependencies, which are specified in pom.xml, one has to use Maven Dependency Plugin:


where ${dependencies.dir} stands for folder where to dump the dependencies.


Why Cyclic Project Dependencies Are Bad

Imagine you have

  • a project projectA with submodules
    • projectA.module1 and
    • projectA.module2
  • a project projectB

projectB dependes on projectA.module1.
projectA.module2 depends on projectA.module1 too and on projectB.

What is wrong here? Cyclic dependency! When