Hi Okay I reverted back to OSGi 4.2 which works.
So OSGi 4.3 is *not* backwards compatible which is a real PITA. So we would need to compile camel-core-osgi / camel-spring / camel-blueprint et all with OSGi 4.2. And then have our fingers crossed that these runs on an OSGi 4.3 runtime? [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.5.1:compile (default-compile) on project camel-core: Compilation failure: Compilation failure: [ERROR] /Users/davsclaus/workspace/camel/camel-core/src/main/java/org/apache/camel/impl/osgi/Activator.java:[437,43] cannot find symbol [ERROR] symbol : method registerService(java.lang.String,org.apache.camel.impl.osgi.Activator.BaseService,java.util.Dictionary<capture#903 of ?,capture#530 of ?>) [ERROR] location: interface org.osgi.framework.BundleContext [ERROR] /Users/davsclaus/workspace/camel/camel-core/src/main/java/org/apache/camel/impl/osgi/Activator.java:[399,48] incompatible types [ERROR] found : java.lang.Class<capture#0 of ?> [ERROR] required: java.lang.Class<T> [ERROR] -> [Help 1] On Mon, Oct 29, 2012 at 3:29 PM, Claus Ibsen <claus.ib...@gmail.com> wrote: > Hi > > Okay it took me a long time to dig into this. I kinda hate the > computer generated MANIFEST.MF files in those 76 cut lines format. > Makes comparing 2 version a big challenge. If at at least the BND tool > could generat a line per package, making diff much easier for humans. > > Only by using a visual diff tool I could spot a problem. > > In Camel 2.10 the MANIFEST.MF is generated with [1.2,2) for the > spring-dm osgi stuff. > > sembler;version="[3,4)",org.springframework.jmx.export.metadata;version > ="[3,4)",org.springframework.osgi.context;version="[1.2,2)";resolution: > =optional,org.springframework.remoting.support;version="[3,4)",org.spri > ngframework.transaction;version="[3,4)",org.springframework.transaction > .support;version="[3,4)",org.springframework.util;version="[3,4)",org.w > 3c.dom > > > But on trunk its using spring framework range [3,4) which is wrong > > sembler;version="[3,4)",org.springframework.jmx.export.metadata;version > ="[3,4)",org.springframework.osgi.context;version="[3,4)";resolution:=o > ptional,org.springframework.remoting.support;version="[3,4)",org.spring > framework.transaction;version="[3,4)",org.springframework.transaction.s > upport;version="[3,4)",org.springframework.util;version="[3,4)",org.w3c > .dom > > > So I would need to figure out in our marvelous build system, to make > it use the old behavior, so it can use the correct version ranges. > > > > > > On Mon, Oct 29, 2012 at 10:57 AM, Babak Vahdat > <babak.vah...@swissonline.ch> wrote: >> Hi >> >> If I remember correctly, yesterday that was also one of my suspections as >> well so that I reverted locally back to 4.2, however still observing the >> same behaviour. >> Also tried downgrading felix-compendium, felix-configadmin and >> felix-framework versions back to what they were before the upgrade to OSGi >> 4.3 and still no change in the behaviour. >> >> I suspect the OSGi POM settings being broken *before* this OSGi upgrade, >> like <camel.osgi.import.defaults> and whatnot. >> >> Babak >> >> >> >> >> -- >> View this message in context: >> http://camel.465427.n5.nabble.com/Builds-on-Jenkins-tp5721653p5721717.html >> Sent from the Camel Development mailing list archive at Nabble.com. > > > > -- > Claus Ibsen > ----------------- > Red Hat, Inc. > FuseSource is now part of Red Hat > Email: cib...@redhat.com > Web: http://fusesource.com > Twitter: davsclaus > Blog: http://davsclaus.com > Author of Camel in Action: http://www.manning.com/ibsen -- Claus Ibsen ----------------- Red Hat, Inc. FuseSource is now part of Red Hat Email: cib...@redhat.com Web: http://fusesource.com Twitter: davsclaus Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen
