So as short term solution, I'm thinking about something like smack-java7-osgi, which depends on smack-extensions, smack-experimental and smack-java7 and provides a method SmackOsgi.activate(), that will have Smack's OSGi bundles in active state when it returns. As far as I understand OSGi, this should be accomplished by calling the activate() methods of the respective SmackInitalizers of the Smack components. I'm not sure, but it appears to be that this would make Smack's declarative services obsolete (correct me if I'm wrong).
I don't know if I got you right, but in this case "smack-java7-osgi" must be a single jar containing all packages from "smack-java7", "smack-core", "smack-extensions", "smack-experimental", "smack-sasl-javax", "smack-tcp" and "smack-resolver-javax". The approach that you used to create "smack-java7" does not work in this case and the OSGi manifest file must export all API packages otherwise anybody is able to use the classes.
- SaslProvider (offered by smack-sasl, required by smack-core)
ATM the is no subproject smack-sasl, only smack-sasl-provided and smack-sasl-javax with the implementations for the platforms. Does this mean that there should be a smack-sasl subproject? Or shouldn't SaslProvider go into smack-core?
- SaslProvider (offered by smack-sasl, required by smack-core)
ATM the is no subproject smack-sasl, only smack-sasl-provided and smack-sasl-javax with the implementations for the platforms. Does this mean that there should be a smack-sasl subproject? Or shouldn't SaslProvider go into smack-core?
That was my fault, I meant: ... offered by "smack-sasl-javax" and "smack-sasl-provided", respectively.