Search code examples
osgiapache-felix

What is bare minimum for an OSGi bundle in Felix using Maven, DS, SCR?

The process of wiring up components in OSGi seems to have evolved over time.

The progression seems to be as follows:

There are so many different libraries and approaches that I need a way to winnow down the options to a reasonable approach. I can't tell when the technologies are duplicate approaches to the same problem or building off each other.

I know I will be using the following:

  • Apache Felix
  • Apache Sling
  • Maven

Beyond that, I want a straightforward technique for bundle creation without any duplication.

Here is a screenshot of a bundle I have created using maven and the following plugins: maven-bundle-plugin, maven-scr-plugin.

OSGi bundle

I notice a lot of redundancy and am not sure what is necessary.

  1. pom.xml Why is the pom.xml included in the jar? Does OSGi needs this to pull dependencies from an OSGi Bundle Repository(OBR)?

  2. MANIFEST.MF This also lists dependencies and refers to the serviceComponents.xml Service-Component: OSGI-INF/serviceComponents.xml

  3. serviceComponents.xml Seems like an extension to the manifest with the XML expression of the SCR annotations. At this point are the SCR annotations in the Java classes irrelevant or is OSGi going to use this XML to find the classes with the annotations? I am guessing if I used iPojo this XML would be replaced by iPojo XML?

  4. scrinfo.xml This is a duplicate of the serviceComponents.xml which only add private="false" to each node.

  5. metatype.xml This seems like some other generated XML but isn't using the SCR namespace.

  6. libs I am guessing these are private dependencies of my bundle that are not exposed to the rest of the system.

I don't like the fact that this is meandering question, but I can't seem to find a reliable picture of what the Apache-Felix implementation of OSGi is looking for and where one technology ends and the other begins. If there is a good diagram somewhere that shows the overlap, that would be helpful, or if someone could narrow it down to a specific recommended stack so I can put some blinders on while sorting through the technical details, that would be great.

Solution

  • Unless you have valid reasons to be concerned about a few extra bytes, I wouldn't worry too much about what the Maven plugins put in your bundle jar.

    From your list AFAICS all files have a good reason to be there, except maybe the jars under lib, which I assume have been included by maven-bundle-plugin being setup to embed those dependencies. It's usually better to have your bundle import those packages from other bundles, so that they can be shared instead of being just used by your bundle.

    If you're working with Apache Sling you could take pretty much any bundles that's under /bundles in the Sling codebase as examples, they are built according to well-established best practices. The Sling codebase does use ServiceTrackers, the Whiteboard pattern and a lot of Declarative Services, and BND under the hood at build time , executed by the Maven plugins.

    I haven't used iPojo myself, I assume it would play well with Sling but we haven't seen a need for that in Sling itself.

    I'm not a fan of using Spring in OSGi applications, it seems like some people are successfully doing that but IMO that's an additional layer that doesn't bring much value compared to plain Declarative Services.