javamavenosgiapache-felixcradle

switching to gradle from maven to manage a osgi big project (>200 bundles)


We have a big (~215 bundles and counting) osgi (felix+springdm) project, build with maven and maven-osgi plugin.

We've several problems with maven way:

1. submodules pom have to inherit from parent pom to take advantage of common variables and dependencies (that's ok) but then parent pom has to include all bundles pom to be able to build everything in together. This kind of circular reference makes much hard to keep all in sync.

2. the individual versioning of subbundles was so complex that it was decided (before I joined the project) to use the same version for all bundles. This means we now update version of all bundles for every release also if just a bunch of them are actually changed. This makes the whole concept of osgi a bit meanless IMHO. Please note that I'm not saying we continue to touch just a minority of bundles, we work on all of them but every release usually contains 1 or 2 features, that affects just some bundles.

3. to do the package and the deploy of the final artifact we need still another submodule that imports all the bundles needed for the deploy (all but a few for tests and mocks). [edited] Note that this aggregation is different from the one in the main pom as it doesn't compile bundles but just pick them from the maven repository.

4. the maven dependency system and the osgi plugin imports are sometimes hard to keep aligned. It's just too easy to forget an import or putting a wrong dependency.

[edited] In every bundle pom there is a section like this: `

         <plugin>
            <groupId>org.apache.felix</groupId>
            <artifactId>maven-bundle-plugin</artifactId>
            <extensions>true</extensions>
            <configuration>
                <instructions>
                    <Export-Package>
                    </Export-Package>
                    <Import-Package>
                        com.google.gson,
                        org.apache.log4j,
                        org.apache.log4j.spi,
                        org.dom4j,
                        com.myinterfaces
                    </Import-Package>
                </instructions>
            </configuration>
        </plugin>`

For all those reasons, we are ok but not perfectly happy with maven. Recently someone proposed Gradle not as a panacea but as a definite improvements over the current situation.

Would you recommend moving to gradle? and in case which would be the best way?

Has someone else experienced the same situation? I think it should be common for all big projects with Osgi.

Disclaimer: I looked for similar questions like:

Buildr, Gradle or wait for Maven 3?

Looking for a good dev environment for OSGi bundles

Maven : OSGI, bundles and multi-modules projects

but either where where not about osgi submodules or not about gradle.


Solution

    1. You can separate the parent and the aggregate maven modules, because currently your parent pom have two roles as you correctly observed. More information can be found in the Maven Introduction to POM.
    2. I'm afraid that bundles version management cannot be become easier unless you use API Tools. Perhaps it would be great if API tools can be integrated as Maven plugin, but I'm not aware of any work in this area. So, you either touch all versions at once or update them each time it is needed. API Tools will greatly help here, but it works only for bundles, which can be imported as Plug-in Projects inside Eclipse.
    3. So, will another aggregator module help here? You can setup several aggregators, which aggregate another aggregators, so you don't end up with one huge aggregator module which lists everything? Because, you may not want to deploy everything, you can setup what to exclude from deploying. Quick google search showed how to do it.
    4. @Neil Bartlett already noted that bnd will take care of your manifest if you've setup your dependencies right. If you need extra tweaking of the defaults, you can always set BND instructions file.

    You can put Tycho in the list of possible tools. It will help you with the dependency management, because you need to specify your dependencies in the Manifest only and it will permit you to use API Tools (but no integration yet). It will however require that you use p2 repositories if you want to skip some headaches (until Tycho has improved their support for depending on Maven artifacts).