Update: I tried using a negative import statement to get the bundle plug-in to leave out the stuff I'm exporting from the imports, and it did remove the exported packages from the manifest's imports. However, that had no effect on loading the bundle - it still complained that the same imports were missing. So the imports aren't a problem. Any ideas?
Jim Babka S/W Engineer, Industry SOA Accelerators (512)838-8180, T/L 678-8180 Starting November 17, my new number will be (512)286-5195, T/L 363-5195 [EMAIL PROTECTED] Jim Babka/Austin/IBM 09/17/2008 01:51 PM To [email protected] cc Subject Re: Embed-Dependency doesn't work OK, using _exportcontents worked beautifully. I have a bundle now that only has the JARs in it, which is exactly what I needed. Thanks again for your help! However, I now appear to be having a problem because the packages that are exported are also identified as imports in the manifest. ----- Manifest ------ Manifest-Version: 1.0 Embed-StripVersion: true Embed-Dependency: *;scope=compile|runtime;type=!pom,inline=true Import-Package: com.ibm.events,com.ibm.events.emitter,com.ibm.webspher e.bo,com.ibm.websphere.fabric.da,com.ibm.websphere.fabric.da.context, com.ibm.websphere.fabric.da.failure,com.ibm.websphere.fabric.da.plugi n,com.ibm.websphere.fabric.da.types,com.ibm.websphere.fabric.da.util, com.ibm.websphere.fabric.event.schema,com.ibm.websphere.fabric.types, com.ibm.websphere.fabric.wscaf.context,com.ibm.websphere.fabric.wscaf .context.impl,com.ibm.websphere.fabric.x2007.x01.context,com.ibm.webs phere.fabric.x2007.x01.context.impl,com.ibm.websphere.product,com.ibm .websphere.sca,com.ibm.websphere.sca.addressing,com.ibm.websphere.sca .scdl,com.ibm.websphere.workarea,com.ibm.ws.bo.service,com.ibm.ws.exc eption,com.ibm.ws.fabric.da.api,com.ibm.ws.fabric.da.api.ejb,com.ibm. ws.fabric.extensions.osgi,com.ibm.ws.ffdc,com.ibm.ws.sca.internal.con tainer.util,com.ibm.ws.sca.internal.proxy.impl,com.ibm.ws.session,com .ibm.wsspi.runtime.component,com.ibm.wsspi.sca.addressing,com.ibm.wss pi.sca.container,com.ibm.wsspi.sca.handler,com.ibm.wsspi.sca.headers, com.ibm.wsspi.sca.message,com.ibm.wsspi.sca.scdl,com.ibm.wsspi.sca.sc dl.impl,com.ibm.wsspi.sca.scdl.java,com.ibm.wsspi.sca.scdl.webservice ,com.ibm.wsspi.session,com.webify.fabric.xml,com.webify.fabric.xml.so ap11,commonj.sdo,javax.naming,javax.xml.namespace,javax.xml.parsers,j avax.xml.stream,javax.xml.transform,javax.xml.transform.dom,javax.xml .transform.stream,javax.xml.validation,org.apache.commons.collections .list,org.apache.commons.jxpath,org.apache.commons.jxpath.ri,org.apac he.commons.jxpath.ri.model,org.apache.commons.jxpath.ri.model.beans,o rg.apache.commons.lang,org.apache.commons.lang.builder,org.apache.com mons.logging,org.apache.xmlbeans,org.apache.xmlbeans.impl.values,org. apache.xmlbeans.xml.stream,org.eclipse.emf.common.notify,org.eclipse. emf.common.notify.impl,org.eclipse.emf.common.util,org.eclipse.emf.ec ore,org.eclipse.emf.ecore.change,org.eclipse.emf.ecore.impl,org.eclip se.emf.ecore.plugin,org.eclipse.emf.ecore.resource,org.eclipse.emf.ec ore.resource.impl,org.eclipse.emf.ecore.sdo,org.eclipse.emf.ecore.sdo .impl,org.eclipse.emf.ecore.sdo.util,org.eclipse.emf.ecore.util,org.e clipse.emf.ecore.xmi,org.eclipse.emf.ecore.xmi.impl,org.eclipse.emf.e core.xmi.util,org.eclipse.emf.ecore.xml.type,org.eclipse.emf.ecore.xm l.type.util,org.eclipse.hyades.logging.events.cbe,org.w3c.dom,org.w3c .dom.bootstrap,org.w3c.dom.ls,org.xml.sax Bundle-SymbolicName: com.ibm.ws.fabric.extension Bundle-DocURL: http://www.ibm.com/ Bundle-Description: This bundle provides the Fabric extensions to WPS that are used by 3rd party and/or customer code. Bundle-Activator: com.ibm.ws.fabric.extensions.osgi.Activator Bundle-ManifestVersion: 2 Bnd-LastModified: 1221675683624 Build-Jdk: 1.5.0 Bundle-Version: 9.0 Bundle-Vendor: IBM Created-By: Apache Maven Bundle Plugin Bundle-Name: Fabric extensions to be used by 3rd party code Tool: Bnd-0.0.255 Built-By: babka Bundle-ClassPath: .,lib/fabric-types.jar,lib/fabric-da-sca.jar,lib/fab ric-da-model.jar,lib/fabric-engine-api.jar,lib/com.ibm.ws.fabric.da.s cdl.jar Embed-Directory: lib Private-Package: (deleted for clarity) ... Export-Package: com.ibm.websphere.fabric.x2007.x01.context.impl;uses:= "javax.xml.namespace,com.ibm.websphere.fabric.x2007.x01.context,org.a pache.xmlbeans,org.apache.xmlbeans.impl.values",com.ibm.websphere.fab ric.wscaf.context.impl;uses:="javax.xml.namespace,org.apache.xmlbeans ,com.ibm.websphere.fabric.wscaf.context,org.apache.xmlbeans.impl.valu es",com.ibm.websphere.fabric.da.context;uses:="com.ibm.websphere.fabr ic.da,com.ibm.ws.fabric.da.api,com.ibm.websphere.fabric.da.types,com. ibm.websphere.sca,commonj.sdo",com.ibm.websphere.fabric.x2007.x01.con text;uses:="org.apache.xmlbeans.xml.stream,org.w3c.dom,org.apache.xml beans,javax.xml.stream",com.ibm.websphere.fabric.event.schema,com.ibm .websphere.fabric.da.util;uses:="org.apache.commons.jxpath.ri.model,c ommonj.sdo,org.apache.commons.jxpath,org.apache.commons.jxpath.ri",co m.ibm.websphere.fabric.types,com.ibm.websphere.fabric.wscaf.context;u ses:="javax.xml.namespace,org.apache.xmlbeans.xml.stream,org.w3c.dom, org.apache.xmlbeans,javax.xml.stream" ------- End of manifest ---------- When I try to use the osgi console that comes with WebSphere Process Server to verify that the bundle is ok, I see the following: -------- Console output ---------- C:\IBM\WID612\runtimes\bi_v61> bin\osgiConsole.bat osgi> ss Framework is launched. id State Bundle ..... (skipping) .... 94 ACTIVE org.eclipse.equinox.registry_3.2.1.R32x_v20060814 95 RESOLVED org.eclipse.jdt.core_3.2.0.v_671 Fragments=50 97 RESOLVED org.eclipse.text_3.2.0.v20060605-1400 100 INSTALLED com.ibm.ws.fabric.extension_9.0.0 osgi> diag 100 [EMAIL PROTECTED]/com.ibm.ws.fabric.extension-9.0.jar [100] Missing imported package com.ibm.websphere.fabric.da_0.0.0. Missing imported package com.ibm.websphere.fabric.da.context_0.0.0. Missing imported package com.ibm.websphere.fabric.da.failure_0.0.0. Missing imported package com.ibm.websphere.fabric.da.plugin_0.0.0. Missing imported package com.ibm.websphere.fabric.da.types_0.0.0. Missing imported package com.ibm.websphere.fabric.da.util_0.0.0. Missing imported package com.ibm.websphere.fabric.event.schema_0.0.0. Missing imported package com.ibm.websphere.fabric.types_0.0.0. Missing imported package com.ibm.websphere.fabric.wscaf.context_0.0.0. Missing imported package com.ibm.websphere.fabric.wscaf.context.impl_0.0.0. Missing imported package com.ibm.websphere.fabric.x2007.x01.context_0.0.0. Missing imported package com.ibm.websphere.fabric.x2007.x01.context.impl_0.0.0. Missing imported package com.ibm.ws.fabric.da.api_0.0.0. Missing imported package com.ibm.ws.fabric.da.api.ejb_0.0.0. Missing imported package com.ibm.ws.fabric.extensions.osgi_0.0.0. Missing imported package com.webify.fabric.xml_0.0.0. Missing imported package com.webify.fabric.xml.soap11_0.0.0. Missing imported package javax.xml.stream_0.0.0. Missing imported package org.apache.commons.collections.list_0.0.0. Missing imported package org.apache.commons.lang_0.0.0. Missing imported package org.apache.commons.lang.builder_0.0.0. Missing imported package org.apache.xmlbeans_0.0.0. Missing imported package org.apache.xmlbeans.impl.values_0.0.0. Missing imported package org.apache.xmlbeans.xml.stream_0.0.0. osgi> ------ End of console input ------ If you notice, the missing packages that it is complaining about are all the packages that this bundle is exporting. So, how do I stop these packages from being identified as imports? For reference, here are the current instructions I'm using for the bundle plugin: ------ Fragment of POM -------- <Bundle-SymbolicName>${pom.artifactId}</Bundle-SymbolicName> <Bundle-Activator>com.ibm.ws.fabric.extensions.osgi.Activator</Bundle-Activator> <Embed-Dependency>*;scope=compile|runtime;type=!pom,inline=true</Embed-Dependency> <_exportcontents>com.ibm.websphere.fabric.*</_exportcontents> <Embed-StripVersion>true</Embed-StripVersion> <Embed-Directory>lib</Embed-Directory> ------ End of fragment of POM ------- Jim Babka S/W Engineer, Industry SOA Accelerators (512)838-8180, T/L 678-8180 Starting November 17, my new number will be (512)286-5195, T/L 363-5195 [EMAIL PROTECTED] "Stuart McCulloch" <[EMAIL PROTECTED]> 09/17/2008 11:26 AM Please respond to [email protected] To [email protected] cc Subject Re: Embed-Dependency doesn't work 2008/9/17 Jim Babka <[EMAIL PROTECTED]> > What I mean is that there were no dependencies at all being pulled in to > the bundle - either explicit or transitive. I have purposely made the > "eclipse-deps" dependency "provided" scope because I really do not want them > to show up in the bundle. I also do not want any transitive dependencies > included, either. All I wanted to be included were the 5 explicit > dependencies that were listed without any scope. However, none of them was > being included - the only stuff in the bundle were the classes that were > directly part of this module. > > In any case, I tried making the changes that you suggested to the > Embed-Dependency tag and adding the Embed-Transitive tag. Sure enough, now I > got all kinds of stuff, including the transitive dependencies that I did not > want. Then I had a thought - I removed the transitive specification but kept > your suggested version of the Embed-Dependencies tag. Success! Now the > bundle has the dependencies I want, so there is apparently a bug that gets > worked around by using the "type=" specification! > interesting - could you provide a standalone test project that recreates the bug and builds without needing access to special repos, etc? ie. your original pom didn't build so I created my own mini-project that used a pom dependency, but unfortunately I wasn't able to recreate the missing dependency issue... without a testcase we'd probably need detailed build logs (ie. mvn -X install) feel free to raise this over at JIRA: http://issues.apache.org/jira/browse/FELIX > However, there is a bizarre thing going on still: the bundle has the JARs I > want in its root directory, but they are also unpacked inside it. So, I have > a JAR with two copies of everything I want - one inside another set of JARs, > and one directly in the bundle's JAR. How can I stop that from happening? I > would be OK with it having just the JARs inside the bundle (because WPS will > unpack inner JARs at bundle deploy time), but however it works, I definitely > don't want two copies of everything. > having two copies of classes, both unpacked and embedded as jars, is a sign that your Embed-Dependency and Export-Package instructions are overlapping Export-Package tells BND to pull in classes found in the named packages from the build classpath and add them to the bundle, Embed-Dependency tells BND to embed (or inline if enabled) whole artifacts in the bundle. so say I have: Export-Package: org.objectweb.asm.* and I have the asm artifact as a compile scope dependency, then I would see the org.objectweb.asm classes unpacked in the bundle, ie. pulled in by BND. say I now decide to embed asm as a jar, for example with: Embed-Dependency: *;scope=compile|runtime I would now see the asm artifact embedded inside bundle - but I would also see the unpacked classes from before, because I'm still asking BND to pull them in (you will probably also see split package warnings during the build). ok - so how do I embed asm as a jar, but mark its packages as exported without pulling in the unpacked classes... well, there is another export instruction added for exactly this reason: -exportcontents: org.objectweb.asm.* ( <_exportcontents> in the pom.xml ) this instruction is merged with Export-Package, after BND has decided on the content of the bundle - that is, it works just like Export-Package except that it won't alter the content of the bundle. so by removing org.objectweb.asm.* from Export-Package and using the -exportcontents instruction instead along with Embed-Dependency, I can now embed the asm artifact in my bundle and export its packages: Embed-Dependency: *;scope=compile|runtime -exportcontents: org.objectweb.asm.* final note: standard Java tools like javac cannot use jars embedded within jars, so you might still need to compile against the original artifacts - but OSGi will be able to see the embedded jar(s) HTH > Thanks for your help so far - I'm a lot farther along than I was yesterday. > > > Jim Babka > S/W Engineer, Industry SOA Accelerators > (512)838-8180 > [EMAIL PROTECTED] > [image: Inactive hide details for "Stuart McCulloch" <[EMAIL PROTECTED]>]"Stuart > McCulloch" <[EMAIL PROTECTED]> > > > > *"Stuart McCulloch" <[EMAIL PROTECTED]>* > -- Cheers, Stuart
