Details
Improvement
Closed
Major
Description
Currently people need to osgify XStream when need to use it in an OSGi environment.
Since Xstream is build by maven it should be easy to add maven-bundle-plugin that creates the manifest dynamically.
Activity
Thanks for making it an OSGi-bundle. Unfortunately com.thoughtworks.xstream.core.util has been explicitely left out from the Export-Package declaration, which seems to be intended, since it is only considered an internal package, but in my use-case is needed so I still need to repackage it.
Not an error in Xstream, just wanted to let you know for possible consideration in upcoming versions.
Ref: <Export-Package>!com.thoughtworks.xstream.core.util,com.thoughtworks.xstream.*;-noimport:=true</Export-Package> in http://svn.codehaus.org/xstream/trunk/xstream/pom.xml
Rico Neubauer
added a comment - Thanks for making it an OSGi-bundle. Unfortunately com.thoughtworks.xstream.core.util has been explicitely left out from the Export-Package declaration, which seems to be intended, since it is only considered an internal package, but in my use-case is needed so I still need to repackage it.
Not an error in Xstream, just wanted to let you know for possible consideration in upcoming versions.
Ref: <Export-Package>!com.thoughtworks.xstream.core.util,com.thoughtworks.xstream.*;-noimport:=true</Export-Package> in http://svn.codehaus.org/xstream/trunk/xstream/pom.xml Hi Rico,
yes, it is left out intentionally. Any class in this package is not part of the public API and might therefore also break binary compatibility even when upgrading a maintenance version (and this has happened, even for 1.4.5). Older versions of XStream left out even com.thoughtworks.xstream.core.*, but failed to avoid those types in the API.
So, why do you think, you need something of c.t.x.core.util and what exactly?
Jörg Schaible
added a comment - Hi Rico,
yes, it is left out intentionally. Any class in this package is not part of the public API and might therefore also break binary compatibility even when upgrading a maintenance version (and this has happened, even for 1.4.5). Older versions of XStream left out even com.thoughtworks.xstream.core.*, but failed to avoid those types in the API.
So, why do you think, you need something of c.t.x.core.util and what exactly? I do have an implementation, that is capable of reading serialized (! not marshalled) JAXB 1.x objects and desiralize them with JAXB 2.0. For this besides other things, I extended com.thoughtworks.xstream.core.util.ClassLoaderReference to be able to work with multiple ClassLoder-references. In 1.4.5, this I could replace with com.thoughtworks.xstream.core.ClassLoaderReference to resolve the not-exported package, however that class is final so is no option.
This is a very specific use-case and I don't expect a general solution from XStream as said; I can work around it by re-bundling and defining the manifest.
Rico Neubauer
added a comment - I do have an implementation, that is capable of reading serialized (! not marshalled) JAXB 1.x objects and desiralize them with JAXB 2.0. For this besides other things, I extended com.thoughtworks.xstream.core.util.ClassLoaderReference to be able to work with multiple ClassLoder-references. In 1.4.5, this I could replace with com.thoughtworks.xstream.core.ClassLoaderReference to resolve the not-exported package, however that class is final so is no option.
This is a very specific use-case and I don't expect a general solution from XStream as said; I can work around it by re-bundling and defining the manifest. Well, com.thoughtworks.xstream.core.util.ClassLoaderReference is now deprecated and will go away anyway. Why don't you simply provide a ClassLoader implementation that is capable of this functionality? XStream's default ClassLoader (CompositeClassLoader) manages also multiple ClassLoader instances, your implementation can do the same. Then you're in line with XStream API and you don't have to fear API breakage by an maintenance update.
Jörg Schaible
added a comment - Well, com.thoughtworks.xstream.core.util.ClassLoaderReference is now deprecated and will go away anyway. Why don't you simply provide a ClassLoader implementation that is capable of this functionality? XStream's default ClassLoader (CompositeClassLoader) manages also multiple ClassLoader instances, your implementation can do the same. Then you're in line with XStream API and you don't have to fear API breakage by an maintenance update. Yes, I have to consider and maybe migrate this. But hoping to be able to drop it completely in the future.
So far I only had to overwrite com.thoughtworks.xstream.core.util.ClassLoaderReference.getReference() to return my ClassLoader[Reference], since this is now used in XStream's constructor. So 1.4.5 works for me.
Rico Neubauer
added a comment - Yes, I have to consider and maybe migrate this. But hoping to be able to drop it completely in the future.
So far I only had to overwrite com.thoughtworks.xstream.core.util.ClassLoaderReference.getReference() to return my ClassLoader [Reference] , since this is now used in XStream's constructor. So 1.4.5 works for me. 
Unfortunately it does not help to add the correct OSGi information into the manifest, especially with all the optional stuff. If you can provide the proper OSGI information, we can configure the plugin accordingly.