Florian Schmaus 4c76f2652d Reworked OSGi support of Smack (SMACK-343) ... Because of OSGi, no subproject of Smack (which is the same as a OSGi bundle) must export a package that is already exported by another subproject. Therefore it was necessary to move the TCP and BOSH code into their own packages: org.jivesoftware.smack.(tcp|bosh). OSGi classloader restrictions also made it necessary to create a Declarative Service for smack-extensions, smack-experimental and smack-lagacy (i.e. smack subprojects which should be initialized), in order to initialize them accordingly, as smack-core is, when used in a OSGi environment, unable to load and initialize classes from other smack bundles. OSGi's "Service Component Runtime" (SCR) will now take care of running the initialization code of the particular Smack bundle by activating its Declarative Service. That is also the reason why most initialization related method now have an additional classloader argument. Note that due the refactoring, some ugly changes in XMPPTCPConnection and its PacketReader and PacketWriter where necessary.		2014-05-15 16:09:37 +02:00
..
carbons	Make ProviderManager static	2014-05-11 09:27:41 +02:00
hoxt/provider	Prefix subprojects with 'smack-'	2014-04-28 19:44:14 +02:00
ExperimentalInitializerTest.java	Reworked OSGi support of Smack (SMACK-343)	2014-05-15 16:09:37 +02:00