I solved the OSGi compatibilty issue of the smack libraries. Please, fix it so that the OSGi community can use your implementation. You do not have to change the code, only “repair” the manifest files and everything runs properly. I refer to the current Smack release 3.3.1.
smack.jar:
Add the smack.providers file from smackx.jar to the folder META-INF. It has been removed in the current release. In 3.3.0 the file was present.
Add the following entry to MANIFEST.MF
Require-Bundle: org.igniterealtime.smack-ext;bundle-version=“3.3.1”;resolution:=optional
Correct the version info:
Bundle-Version: 3.3.1
smackx.jar:
Add the following entry to MANIFEST.MF
Require-Bundle: org.igniterealtime.smack;bundle-version=“3.3.1”
Correct the version info:
Bundle-Version: 3.3.1
Add your release to Maven Central.
I have attached the corrected manifest files. MANIFEST.MF (3023 Bytes) MANIFEST.MF (9394 Bytes)
Regarding adding smack.providers to smack.jar: ATM I am unable to identify the commit that caused the changed, it could be related to SMACK-381, and I am not sure if we want to change this back, since the smack.providers depends entirely on code found in smackx and not smack. Why do you need the change for OSGi compatibilty anyways?
The Build-Version beeing 0 in the 3.3.1’s MANIFEST.MF is strange, that is definately wrong. And the Require-Bundle metadata seems to make sense.
Anyway, it seems what you are reporting is a regression of the OSGi functionality. I have reopened SMACK-343.
The removal of the providers file is news to me as well. I will have to look to see why that happened, as it should be there. Same with the versioning.
As for OSGi, I would prefer a solution that didnt use **Require-bundle**, as that is a bit of a hack (a necessary one in many cases) in the OSGi world in itself, but it may be the only reasonable one due to the way Smack currently configures itself. I use Smack extensively in OSGi myself, but I simply created a single bundle from smack and smackx to work around this issue. Personally, I prefer this solution as doesnt require the usage of Require-bundle attributes and well, the deployment only requires one bundle instead of two. The downside is of course that it does pull in all of Smack instead of just the core.