Thursday, April 11, 2013

Maven groupId:artifactId and OSGi Bundle-SymbolicName - how they relate to each other?

OSGi massively coming to the maven world is a new trend, and is causing quite a big disturbance (at least to me).

First of all, as you already know, Fedora policies don't allow me to use binaries. Therefore Eclipse Orbit, a project that contains 3rd party Eclipse dependencies in the form of jars, is banned for me.

I witness that more and more open source jars support OSGi by default, but sometimes not exactly in the way I'd love to - especially if it comes to the naming schemes.

Let's look at the example of JDT core - the most widely used Eclipse jar. It was used as a maven dependency long before it received its official pom. As a result, it is available in Fedora with following aliases:
  • org.eclipse:jdt.core
  • org.eclipse.tycho:org.eclipse.jdt.core
  • org.eclipse.jetty.orbit:org.eclipse.jdt.core
  • org.eclipse.jdt:org.eclipse.jdt.core
The question is, which is the right one? Well, the OSGi Bundle-SymbolicName wiki page says that:
A BSN often takes the form of a reverse domain name. If automatically generated via Maven Bundle Plugin, takes the form ${pom.groupId}.${pom.artifactId}, or ${pom.artifactId} if it already starts with ${pom.groupId}.
So, in that case, we need to go the Maven Guide to Naming, and find out that:
groupId will identify your project uniquely across all projects, so we need to enforce a naming schema. It has to follow the package name rules, what means that has to be at least as a domain name you control, and you can create as many subgroups as you want. Look at More information about package names.
artifactId is the name of the jar without version. If you created it then you can choose whatever name you want with lowercase letters and no strange symbols. If it's a third party jar you have to take the name of the jar as it's distributed.

The artifactId for Eclipse should be a jar name, which in turn should follow Eclipse Naming conventions. The groupId should be a reverse domain name of the project, so in case of JDT, we would get org.eclipse.jdt, thus the final and proper groupId:artifactId of JDT core is org.eclipse.jdt:org.eclipse.jdt.core.

The real problem will appear if the project does not obey Maven guidelines, and has groupId:artifactId commons-logging:commons-logging or junit:junit. In that case applying OSGI guidelines will cause invalid Bundle-SymoblicNames: commons-logging and junit, which are against OSGi guidelines, although based on them.

In this situation it would be good to reconsider group and jar name changes to reflect the organization domain:
  • org.apache.commons:logging (logging.jar shipped)
  • org.junit:org.junit (org.junit.jar shipped).
Happy renaming!


  1. Your post assumes we know what's a project, but isn't org.eclipse our project (the one that ships the SDK)? OTOH, I'm a committer on the org.eclipse.jdt.core project, or is that not a project??

    So which level of granularity defines the groupId?


    1. Hey Stephan,

      It's a very good point!

      Actually I'm not sure how to answer this, because Eclipse is a project (org.eclipse), jdt is a project (org.eclipse.jdt) and jdt.core is a project (org.eclipse.jdt.core). I have a habit of distinguishing projects up to the 3rd segment of their name, mostly because it's Eclipse (org.eclipse) and a project name as refered in the project website ( The latter site says that jdt.core is a part of jdt, which, I think, addresses your doubt.


  2. I had a similar problem. You can find my solution and reasonings here: