JMX package import versions

[Holly Cummins <ho...@googlemail.com>]

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

Re: JMX package import versions

[David Bosschaert <da...@gmail.com>]

Hi Holly,

On 20 July 2012 17:03, Holly Cummins <ho...@googlemail.com> wrote:
> Thanks David, that helps me understand what's going on. Based on your
> explanation, though, it seems to me like jmx actually needs to be
> fairly closely coupled to the framework version. Backwards
> compatibility isn't enough, since the jmx classes actually implement
> the framework interfaces. For example, in
> org/apache/aries/jmx/Framework, we implement FrameworkMBean. There's a
> new method, getDependencyClosure(), on v1.7 of FrameworkMBean. Won't
> we risk NoSuchMethodExceptions if we import version of 1.7 of the
> org.osgi.jmx.framework package and the getDependencyClosure() method
> on the interface gets driven? Or am I not getting how the bean would
> be used?

Good point, and you are correct, we cannot depend on MBean API version
1.7 but we can work with 1.7 framework APIs.

Cheers,

David

Re: JMX package import versions

[Holly Cummins <ho...@googlemail.com>]

Thanks David, that helps me understand what's going on. Based on your
explanation, though, it seems to me like jmx actually needs to be
fairly closely coupled to the framework version. Backwards
compatibility isn't enough, since the jmx classes actually implement
the framework interfaces. For example, in
org/apache/aries/jmx/Framework, we implement FrameworkMBean. There's a
new method, getDependencyClosure(), on v1.7 of FrameworkMBean. Won't
we risk NoSuchMethodExceptions if we import version of 1.7 of the
org.osgi.jmx.framework package and the getDependencyClosure() method
on the interface gets driven? Or am I not getting how the bean would
be used?

On Fri, Jul 20, 2012 at 1:46 PM, David Bosschaert
<da...@gmail.com> wrote:
> 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 <ho...@googlemail.com> 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

Re: JMX package import versions

[David Bosschaert <da...@gmail.com>]

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 <ho...@googlemail.com> 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