Hi Holly, Yes, JMX is a bit of interesting spec in that the packages are not versioned on their own, but rather follow the version of the packages that they mirror over JMX.
So for example org.osgi.jmx.framework mirrors org.osgi.framework and org.osgi.jmx.service.cm mirrors org.osgi.service.cm and so on. To make it clear what API implementation a JMX package belongs to it uses the same version number as its source API. The org.osgi.jmx.framework specified in Enterprise 4.2 mirrors the org.osgi.framework from Core 4.2 which has package version 1.5. Enterprise R5 JMX mirrors Core R5 which has package version 1.7. Having said all that, org.osgi.framework has not changed in backward incompatible ways since 1.5 so the org.osgi.jmx.framework version 1.5 should be usable with a 1.7 org.osgi.framework (it just won't provide the new bits over JMX). I think the correct dependency for it on org.osgi.framework would be [1.5, 2). Best regards, David On 20 July 2012 13:31, Holly Cummins <[email protected]> wrote: > I've added version ranges to the JMX package imports. The version of > the org.osgi.jmx.framework package, which we implement, changed from > 1.5 to 1.7 between r4.2 and r5 of the enterprise spec. This means > version 1.0.0 of our jmx-bundle won't resolve against r5 enterprise > APIs. Is this what you expected, David? > > I guess this is why we've got a jmx-next. :) > > (All of the other org.osgi.jmx.* packages either stayed unchanged, or > changed but we don't implement them.) > > Holly
