1

At the moment, developers work on multiple OSGi Bundles which also use each other via OSGI import/export. Eclipse is used for developing and testing.

Now, we are going to set up a CI-server (Jenkins) which should build all the osgi bundles (from the repo) by using Maven. Consequently, only in the CI-server is a need for maven. That also means, developers neither see nor care about a pom.xml when develop on their workstations because they dont get in touch with maven.

My first Question would be, if it is possible to to so. When developer change imports and exports on the Manifest, maven has to know that to make these dependencies available for the compiler. For example maven wants to build BundleB which imports package a from BundleA. Normally, a pom.xml would include a maven-dependency on Bundle A (which has to be deployed to the local maven repo before). But there is no entry in the pom.xml when developers only change their MANIFEST.MF in their bundles. Is it possible that maven determines correct maven-dependencies from parsing the MANIFESTs ? Or another solution: tell maven a classpath with all pre-built jars?

My second question would be if it is recommended to use maven only on a ci-server but not at the developers.

Regards

J. Doe
  • 91
  • 1
  • 8
  • See also [this answer](http://stackoverflow.com/a/11373010/1744774) to [Should I use POM first or MANIFEST first when developing OSGi application with Maven?](http://stackoverflow.com/q/11373009/1744774) for a comparison of POM first vs. MANIFEST first. – Gerold Broser Apr 07 '16 at 18:05

1 Answers1

2

If the developers do not use maven then what do they use for the build. I think it makes sense to have an automated build system. So you should use either maven or something similar like gradle on the developer system.

The other question is if it makes sense to maintain Manifest files by hand. It is the way the PDE works in eclipse but I think it is much more effective to create the Manifest during the build. This can be done by using the maven-bundle-plugin from felix. It is much easier to work like that.

For some examples see the karaf tutorials.

Another option you could pursue is to look into bndtools and their gradle builds. It is a little special but very convenient.

Christian Schneider
  • 19,420
  • 2
  • 39
  • 64
  • Actually, our developers dont really build. They compile+run their osgi bundles inside eclipse (which basically is an osgi container). – J. Doe Apr 07 '16 at 15:08
  • 1
    Well ... I know that style of work from a decade ago ... :-) Jokes aside .. the problem is: If the developer can not build the application how can he make sure the build on the CI server will work? – Christian Schneider Apr 07 '16 at 15:09
  • Until now, developers always have to check out the complete product (multiple osgi bundles / projects) and created the final osgi-bundle-jars by using the export-function of eclipse. Now, developers should still check out the complete product and test them in their local Eclipse environments. But the new thing should be that a CI server builds the osgi bundles and as a next step, there should be automated integration tests in an osgi-container which only runs the application and not this eclipse-equinox mix which the developers use. – J. Doe Apr 07 '16 at 15:23
  • 1
    Makes sense but I would use the same build for developers and the CI machine. So the developers can do the build and only check in if all works on their machine. This leads to less failed builds and keeps the code base at high quality. – Christian Schneider Apr 07 '16 at 15:25
  • But... When developers build in the same way like CI does... Why do people use CI? – J. Doe Apr 07 '16 at 21:46
  • 1
    The CI provides a "neutral" environment that is not affected by the develper. I often had cases where a build worked for me but not on the CI system. Typically I either had some special setting or for example a snapshot in my local maven repo that was not available elsewhere. So while the developer build is a good thing you always also need a build on a neutral instance to make sure the build does not only work on the single developer machine. – Christian Schneider Apr 08 '16 at 07:54