Hello everyone!
I am in the process of converting 95 bundles created and developed within a PDE workspace over the past ~20 years to bndtools. Quite big task, nice to learn a lot of stuff, also nice to get a lot of headaches, but mostly the good-pain kind 
So I’ve been running into lots of weird problems mostly having to do with dependency management (and dealing with ooooold libraries) and the differences between how PDE and bndtools approach/implement OSGi…
So far so good, other than the abysmal state of bndtools’ documentation, which I knew before will be a tough pill to swallow, mostly by finding out about some of the cool stuff that is only partially documented, I’ve actually come very far and am pretty happy about how everything turned out. That is until I just found a potential dealbreaker, which if not resolvable might have me need to throw in the towel for economic reasons.
Edit: The previous sentence was exaggerated, but such a major redesign of our main product is gonna stir up big discussions in our team.
I’m running into a problem where some of our bundles are fragments containing annotated DS @Components, which do get activated in the PDE workspace, yet not in bndtools.
One of their Fragment-Hosts has Eclipse-ExtensibleAPI: true in its Manifest, yet I don’t know whether this is the reason its fragments’ @Components get activated, while that doesn’t happen in bndtools.
I’ve come pretty far in this whole conversion, 74 of those bundles are sitting happily in my bndtools workspace, not throwing errors during build time, all resolving as they should (or how I at least guess they should) in runtime also running smoothly until services get called with their @Component annotated implementations being located in a fragment bundle, as these somehow don’t end up in the OSGi service registry.
Of course this leads to functionality breaking, as org.osgi.framework.ServiceExceptions get thrown left right and center.
Can I, without restructuring those fragments to independent bundles, replicate the PDE behaviour in bndtools?
Cheers
Julian
Hi @jkoerkel ,
not that I know an answer, but a few questions:
I think it is a limitation of OSGi that Fragments do not participate in normal bundle lifecycle.
Does your current Fragment bundle really need to be fragment bundle? If yes, what was the reason?
Could you move the @Components class from the Fragment bundle to another normal bundle?
OK sorry I overread your most important sentence. Hmm not sure you can avoid that.
Since the fragment shares the same classpath with the host (the host can see classes in its fragments) you may do some classpath classloader scanning tricks in the host and find specific classes in the fragments and instanciate them.
I am sure you already found this article by @fipro78 which I think describes your problem.
Edit:
Just in case you don’t know: The OSGi bnd Snapshot Viewer was a valueable tool in a few cases when I migrated to bndtools.
1 Like
I think it is a limitation of OSGi that Fragments do not participate in normal bundle lifecycle.
Yeah we had a lot of issues in the codebase where we deviate from how things actually should be done in OSGi, yet this one unfortunately is a little larger then my previous problems in this conversion…
Does your current Fragment bundle really need to be fragment bundle? If yes, what was the reason?
… cause let’s talk more like… 20ish fragments or so. Why we did this really only makes sense when talking about what our products are supposed to do in German (not at liberty to explain) and suddenly the idea of Fragments extending their hosts’ apis like this becomes a no-brainer, yet the moment this is taken out of a PDE context, it obviously fails. So now I’m probably gonna be overstaying my welcome with my team because this entails a rather substantial redesign of our main product, where what I was supposed to do is just to make a different build system work with our existing products, so no manual upkeep of Manifests is necessary and use its more strict warnings to after conversion, not before, fix our problems with how we’ve been doing some key aspects of OSGi development not completely the right way.
Could you move the @Components class from the Fragment bundle to another normal bundle?
That unfortunately grows the host bundle substantially and the split into fragments was done so we have a better overview of our general project structure. So this would just dissolve the fragments and put them back in an already already very big host bundle…
Interesting case. I never realized, that Components inside a Fragment don’t work OOTB. This ahs nothing todo with bnd though. SCR does simply not look for a Service-Component Header in Fragments. The solution is rather simple though, as I just found out. Add Service-Component: OSGI-INF/* to the Manifest of your Host Bundle and now it will work as you expect.
2 Likes
That explains a lot, because in the PDE projects, their manifests have Service-Component: OSGI-INF/components/*.xml set, yet I didn’t do that in my bnd.bnd-files, as the Service-Component Header is set by bndtools. Then I’ll add that back and report back whether that solves my problem.
Thank you!
Related SO-Answer
That has solved my problem. Thanks a lot!
1 Like