Should I use POM first or MANIFEST first when developing OSGi application with Maven?

Question

There are two main approaches when developing an OSGi application with Maven: POM-first and MANIFEST first.

I'm looking for an answer that is in a form of a table that shows pros and cons of each method.

To be more specific, I would also like to know how it relates to:

• Maturity of toolset
• Vendor independence
• Development ease (which includes finding people who can do the development on the tooling)
• Compatibility
• Avoiding ClassNotFound
• Avoiding manual work

Floria

"We play BOTH kinds of music here... Country and Western." In other words you've set out a false dichotomy, and there are more choices than "POM first" and "MANIFEST first". In particular have you looked at the Bndtools IDE? – Rebellious

This question obviously falls in the category of soliciting debates and arguments and should be closed. – Chesser

I only know of two methods to deal with this: maven-bundle-plugin and tycho-maven-plugin. I am in the middle of converting my Eclipse plugin to use Tycho right now so I have a "real" reason to use it. And my reference OSGi app with is not Eclipse based is using Felix. So far I am seeing more cons with Tycho as I use it. – Floria

Answer 1

At present this is what I can come up with

POM-First Pros (using maven-bundle-plugin)

• Leverages existing Maven skills, repositories and tooling.
• Likely easier to find people who know how to manage pom.xml rather than MANIFEST.MF along with pom.xml
• Most of the information in MANIFEST.MF can be obtained from the pom.xml itself.
• Can work with other IDEs not just Eclipse based ones.
• Less invasive, just add the single plugin and change the packaging type to "bundle"

POM-First Cons

• ClassNotFoundException more likely to occur at runtime. However, this can be mitigated using pax-exam (although it is very complicated to set up).
• Still need to understand how the MANIFEST is setup to make sure the instructions configuration element is set correctly.

MANIFEST-first Pros (using tycho-maven-plugin)

• Seems to be the recommended approach, or at least talked about as the recommended approach, but I can't really see why it has significant benefit. (Hence why this question was asked).
• Good for developing Eclipse plugins and integrates well with PDE
• Provides tooling for testing thus allowing ClassNotFoundException to appear during JUnit testing rather than runtime.

MANIFEST-first Cons

• Seems to only work well on Eclipse based IDEs. You don't have to use Eclipse, but without the PDE would you want to?
• Violates DRY principles since I have to do put keep the names and versions from the POM and MANIFEST.MF in sync.
• Need to name things in a specific fashion
• You cannot mix, meaning existing Maven multi-project installations cannot just tack on OSGi support
• A lot more configuration compared to maven-bundle-plugin is needed to get less warnings: http://wiki.eclipse.org/Tycho/Reference_Card#Examplary_parent_POM
• Have to make test cases a separate project. It won't run when built in src/test/java.
• Seems that it will only test classes that are exposed, in other words those in ".internal." is not testable.

If I were asked for a recommendation for an enterprise that is using Maven already and want to move to OSGi then it would be POM first

If I were asked for a recommendation for someone who is doing Eclipse plugin development, then it is Manifest first -- with tycho

Floria

Is there a way to generate POM dependencies from MANIFEST.MF? – Reardon

Tycho provides such functionality. It can also keep the versions in sync. – Gus

Answer 2

I think you should choose by use case. For server side OSGi projects I favour the pom first style. It nicely matches the maven builds and is much less error prone than Manifest first. In fact bnd which is behind the maven bundle plugin gets the Manifest right for most cases without any additional config. The trick is to use some naming rules. For example if you name internal package impl or internal the will not be exported. Using this style you can not use the Eclipse plugin perspective (at least without bndtools which I do not like) but I did not yet miss this perspective. I am a developer in the Apache Karaf, CXF and Camel projects where we use this style and it works great. Especially for CXF and Camel it is great that we can support OSGi and non OSGi deployments with the same build and tools.

For Eclipse RCP applications Manifest first is the way to go as you need the plugin perspective and the Eclipse IDE tools. If you want to combine that with maven then tycho is probably the way to go.

Hoeg

I found the exact same thing to be true. I have also developed in both methods, and continue to do so when appropriate. This is why we use Tycho for our RCP code, so we can still use maven but it allows for easier development in Eclipse for RCP by making the manifest king. – Chesser

Thanks, your conclusions match mine, actually your conclusions was what I thought of before I even wrote the question. The reason for the question is to list the pros and cons for each in case I have to justify why I chose one over the other. – Floria

Answer 3

MANIFEST first does not lock you to Eclipse (although I'd be surprised if more than a tiny minority would use anything else). The MANIFEST is the file that counts, and needs to be added to a jar, regardless how you do that.

On the other hand, POM first completely locks you to Maven, you lose the advantage that an OSGi bundle is a regular jar you can make any way you want.

I've tried both, I really prefer MANIFEST first. The MANIFEST file is a really important file, I prefer to craft that file over crafting a file that produces that file. If something weird happens, (and it will at some point) the MANIFEST file is the first to check, it's just easier if it's your own file. Besides, you will have to be familiar with it anyway.

So, if Maven is your alpha and omega, POM first will suit you best, but you'll still need to have in-depth understanding of the MANIFEST file.

Formalize

I couldn't disagree with this position more, it's far better to generate MANIFEST than to manually maintain it, because it contains so much duplicated information (e.g. the imported packages). The argument about it being very important is bogus, because the .class files in your application are also very important, and you wouldn't dream of writing those by hand. – Rebellious

Interesting. I'm not against generating a MANIFEST file, I'm just saying that you do need to be familiar with it anyway. Many problems showing up at stackoverflow can be solved or analyzed by looking at the MANIFEST file. I've never seen anyone request bytecode. The two do have a different role. Anyway, I look forward to your answer. – Formalize

Yes .. you have to know how your Manifest should look like. When You generate the manifest you still have to check it works well but you have a lot less manual work. So I also support rather generating the Manifest. – Hoeg

@FrankLee If you're editing the Manifest by hand, how do you make sure you get all the versions and "uses" directives right? Sounds very error-prone... – Milanmilanese

@FrankLee Time to party! First comment, first sentence: "Have you checked the bytecode?". ;) – But