It looks to me like jmx-core has the same issue, unfortunately, and it's already been released. However, I agree we should fix this where we can, so I'll remove jmx-bundle from the release, roll all the tags back, and fix up its pom. I don't think that will push back the date when we have the whole component released and can move to jmx-next.
Good spot, Tim. Thanks. On Fri, Jul 20, 2012 at 7:41 AM, David Bosschaert <[email protected]> wrote: > On 19 July 2012 23:05, Timothy Ward <[email protected]> wrote: >> >> Hi, >> >> All four build fine, and the poms/manifests for three of them are fine. >> Unfortunately the manifest for jmx-bundle doesn't use version ranges in most >> of its imports: >> >> Import-Package: javax.management,javax.management.openmbean,org.apache >> .aries.util;version="[1.0,2)",org.osgi.framework;version="1.5.0",org. >> osgi.jmx;version="1.0.0",org.osgi.jmx.framework;version="1.5.0",org.o >> sgi.jmx.service.cm;version="1.3.0",org.osgi.jmx.service.permissionadm >> in;version="1.2.0",org.osgi.jmx.service.provisioning;version="1.2.0", >> org.osgi.jmx.service.useradmin;version="1.1.0",org.osgi.service.cm;re >> solution:=optional;version="1.3.0",org.osgi.service.log;version="[1.3 >> ,2)",org.osgi.service.packageadmin;version="[1.2,2)",org.osgi.service >> .permissionadmin;resolution:=optional;version="1.2.0",org.osgi.servic >> e.provisioning;resolution:=optional;version="1.2.0",org.osgi.service. >> startlevel;version="[1.1,2)",org.osgi.service.useradmin;resolution:=o >> ptional;version="1.1.0",org.osgi.util.tracker;version="[1.4,2)" >> >> I think all of these are set in the pom - I'm not sure if the right answer >> is to remove all of the versions in the <aries.osgi.import> tag and let the >> bundle plugin figure it out, or to put in the right version ranges. The >> former is more maintainable (and nicer) but might not give the intended >> result. >> >> I'm sure we all agree this is a showstopper. If I can +1 the three other >> bundles and ask for the jmx-bundle to be fixed/respun then great, otherwise >> I'm afraid David will have to wait a little longer. Sorry! > > Main reason I'd like to see this one out is to get a release of the > 'old' JMX. I implemented 'jmx-next' in the sandbox already, but we > agreed that it would be good to get a release of what was there before > upgrading. > > So I'm not sure it's needed to fix the old JMX, as it will soon be > superceded anyway. But I will look at the jmx-bundle in jmx-next to > ensure that it uses version ranges. > > In any case I'm fine with either option if someone has time to fix > this issue in the old JMX... > > Cheers, > > David
