Flow schrieb:
The approach that you used to create "smack-java7" does not work in this caseHmm, why? OSGi bundles transition into the activated state once a class they export are used. So we have smack-java7-osgi that has an Import-Package declaration containing all the packages form the Smack bundles smack-core, smack-extensions, smack-sasl-javax and so on. Then in smack-java7-osgi there is SmackOsgi.activate() which calls the activate() method from each of those Smack bundles. Once the method returns, Smack is fully activated.
Or am I missing someting?
See the problem from the consumer side: The problem is when my bundle imports packages e.g. from "smack-core" and my bundle gets activated, there is no gurantee (missing service layer) that "smack-java7-osgi" is activated before my bundle got activated, so the "activate" methods were not called. Package dependencies do not (unfortunately) influence activation order and I call e.g. new XMPPTCPConnection(..) but the SASLMechanisms were not added, because "smack-sasl-javax" gets activated later. If I would use the XmppConnectionBuilderFactory service from the OSGi registry instead, I would know that the bundle that provides the service has been activated before. The problem requires adequate service dependenices or a monolic bundle without any service where your init process will make sure that everything is setup. In this case we can rely on the init process that is triggered by classloading in Smack (e.g. AbstractXmppConnection) via this: "static { SmackConfiguration.getVersion(); }"