The issue is less the impl version than it is the api version. The API version is just "2.1", not 2.1.13. What happens if the system is exported as 2.1 and we then add a "real" osgi engabled version that is also 2.1? The API's are exactly the same, is just the "FactoryFinder" class that is really different. We DEFINITELY need to make sure we get the "osgi" version of the 2.1 so it would find the 2.1.13 impl bundle.
Kind of wondering if davidb's stuff in Aries would come into play better here....... Dan On Tuesday, July 12, 2011 11:55:30 PM Christian Schneider wrote: > I don`t really understand why it should not work to export the system > package as the version it really is. > So if the jdk 1.6 exports 2.1.0 for example we should export it as that. > > Then a bundle could still require the version 2.1.13 and it should then > take a separate version from outside the jdk. > > Christian > > Am 12.07.2011 23:23, schrieb Daniel Kulp: > >> javax.xml.bind;version=2.1, \ > >> > >> This way I was able to make sure that jaxb isn't provided as 0.0.0.0 > >> which is usually picked up during > >> resolving. Like Neil Bartlett mentions in his blog > >> http://njbartlett.name/2011/02/09/uses-constraints.html > >> > >> I would suggest since the jre.properties are already split up between > >> 1.5 and 1.6 java version > >> to add those versions to the crucial parts of the jre.properties. > > > > But that doesn't actually work. If you NEED to get a JAXB 2.1.13 > > installed into the JRE due to the fact that the version in anything > > other than the latest JRE is buggy (leaks memory and locks > > classloaders, for example), just doing that won't work. You need to > > actual API jar that has the osgi extensions in it. > > > > Dan -- Daniel Kulp [email protected] http://dankulp.com/blog Talend - http://www.talend.com
