Thanks for your reply...I've sort of figured out the ways to play with import / export package and things to include or exclude. I was bit overwhelmed at the begining but with feedback from all of you guys and playing with it I think I've figured out the concept now.
On Wed, Jun 15, 2011 at 12:20 AM, Per-Erik Svensson <[email protected]> wrote: > Have not read everything but from the OP it looks like your're missing a > couple of exports in your OSGi runtime. Embedding these dependencies (with > Embed-Transitive) in your bundle does not affect the > Import-Package/Export-Package (as far as I know) so you need to change your > pom to no longer Import these packages. You're stating in the pom that you > want maven-bundle-plugin to import everything (*). This means you will have > a manifest file that has import statements for your embedded packages too > most likely. (Just check your built manifest.mf) > > To resolve this, make your import-package tag like this: > > <Import-Package>!com.caucho.burlap.client, !com.caucho.burlap.io, > !com.caucho.burlap.server, com.test.taxonomy.message.*;version=1.0.0, > *</Import-Package> > > and of course new "!embedded.package.that.fail.to.resolve" for each failing > package until your bundle starts. This says that you want to import > everything except the packages listed with a ! in front. (And as I remember, > the order is important. You can't remove an imported package with ! so make > sure to list the non-wanted packages before listing the wanted packages. > That is, * should be appearing last in the tag.) > > Hope this helps and that I understood your problem correctly. :) > > Per-Erik Svensson > > > > On Wed, Jun 15, 2011 at 12:56 AM, Justin Edelson > <[email protected]>wrote: > >> I don't understand why you're dealing with embedded at all in this >> case. com.projectB is being imported from another bundle, so what are >> you embedding? >> >> Maybe post your whole pom on gist or pastebin. >> >> If your bundle is importing packages from commons-lang, then those >> packages must be exported by some other bundle. Not clear that's the >> case here. >> >> Justin >> >> On Sat, Jun 11, 2011 at 2:41 PM, Shamik Bandopadhyay <[email protected]> >> wrote: >> > Justin, again thanks for your inputs. >> > >> > Extending your example of Project A, B and C, but I'm not keen on >> > knowing the transitive dependencies of B, which might be using 2.0 >> > version of C. A also has a dependency on commons-lang 2.5. I've >> > constructed the following plugin bundle entry. >> > >> > <configuration> >> > <instructions> >> > <Export-Package>com.projectA.*;version=1.0.0, >> > </Export-Package> >> > <Import-Package>com.projectB.*;version=1.0.0, >> > * >> > </Import-Package> >> > <Bundle-SymbolicName>${pom.artifactId}</Bundle-SymbolicName> >> > <Bundle-Version>${pom.version}</Bundle-Version> >> > >> <Embed-Dependency>*;scope=compile|runtime;artifactId=!commons-lang|projectC</Embed-Dependency> >> > </instructions> >> > </configuration> >> > >> > I'm deliberately skipping the gathering of transitive dependency >> > information by using * in import package. I'm expecting plugin will >> > include projectC as part of the import package. Also,I'm instructing >> > maven to embed all dependencies it can observe during compile and >> > runtime, but exclude commons-lang and projectC since I'll be relying >> > on OSGi version in Felix. >> > >> > Once I create the bundle and install in felix, it throws an error >> > complaining about commons-lang 2.5 version. My understanding is felix >> > might be running a different version of commons-lang than 2.5. Same >> > can be applicable for projectC as well. So what are my options in this >> > case? Should I make embed-transitive true and let projectC 2.0 and >> > commons-lang 2.5be embedded inside the bundle or install the versions >> > in felix and then install the bundle ? >> > >> > On Fri, Jun 10, 2011 at 8:24 PM, Justin Edelson >> > <[email protected]> wrote: >> >> On Fri, Jun 10, 2011 at 6:34 PM, Shamik Bandopadhyay <[email protected]> >> wrote: >> >>> Justin, >> >>> >> >>> Thanks for your insight. It is indeed helpful to get the concept and >> >>> suggestion from people who have dealt with it on their own. It >> >>> apparently makes sense to use OSGI bundles in a framework meant for >> >>> that, but in an open-source java world, it'll never be easy to have a >> >>> corresponding OSGi bundles for a standard jar. So,I guess, there'll be >> >>> a need for embedding libraries at times. >> >> >> >> I'll quibble with one thing here if you're using Open Source Java >> >> libraries which aren't available with proper OSGi headers in their >> >> standard distribution, it's *very easy* to fix this - just submit a >> >> patch to the project. Although there are some which won't be >> >> interested, I think you'll find that most would be receptive. And for >> >> those that aren't interested in applying your patch, just deploy a >> >> locally patched version to your local Maven repository manager. >> >> Compare this with commercial dependencies where you have little to no >> >> agency. >> >> >> >>> >> >>> The issue I see with maven-bundle-plugin is the ease to adopt. Though >> >>> it looks fairly simple at the first glance, it does require some kind >> >>> of guessing. Atleast, that's what I feel based on my experience, as >> >>> well from Sam's feedback so far. >> >>> >> >>> <<2) don't use transitive embeds - list all dependencies to be >> >>> embedded with a scope of compile and use the scope selector to pick >> >>> all compile scope dependencies>> >> >>> I've couple of questions based on your inputs. You've suggested not to >> >>> use Embed-Transitive, rather, list all dependencies with a scope >> >>> compile. When you say all dependencies, I guess, you meant it by the >> >>> depenedencies defined in the pom. How about the transitive >> >>> dependencies ? How they'll be resolved ? >> >> >> >> Not sure I understand the question, but I'll take a stab at it and say >> >> that this is part of the magic of bnd :) >> >> >> >> Let's say you have ProjectA which depends upon ProjectB which depends >> >> upon ProjectC. ProjectC is already available as an OSGi bundle. >> >> Project B is not and you decide to embed ProjectB into ProjectA. When >> >> bnd does its analysis, it reads bytecode from ProjectA and ProjectB >> >> and determines that one of ProjectC's packages is used. As such, >> >> com.myco.projectc (or whatever) is added to the import list. >> >> >> >>> >> >>> <<4) finally, iteratively tweak the auto-generated imports>> >> >>> You mean altering the imports in generated manifest file ? >> >> >> >> No. I mean in the configuration of the maven-bundle-plugin. My point >> >> here is that bnd's default behavior against the full class space >> >> (including embedded JARs) should be the baseline. Once you see what >> >> bnd does by default, *then* start modifying the pom.xml to deviate >> >> from the default. >> >> >> >> HTH, >> >> >> >> Justin >> >> >> >>> >> >>> On Fri, Jun 10, 2011 at 2:22 PM, Justin Edelson >> >>> <[email protected]> wrote: >> >>>> I would highly recommend not using resolution=optional with * >> >>>> >> >>>> It would be very atypical for *all* imports to truly be optional. When >> you use optional imports blindly like this you will inevitably end up with >> the wrong class space at some point. >> >>>> >> >>>> What I generally advise people is this: >> >>>> 1) deal with embedding first. >> >>>> 2) don't use transitive embeds - list all dependencies to be embedded >> with a scope of compile and use the scope selector to pick all compile scope >> dependencies >> >>>> 3) once embedding is configured, configure the exports (if any) by >> explicitly listing the packages and versions >> >>>> 4) finally, iteratively tweak the auto-generated imports >> >>>> >> >>>> Shamik - I'd suggest you file bug report with a reproduceable test >> case. >> >>>> >> >>>> Justin >> >>>> >> >>>> On Jun 10, 2011, at 5:08 PM, sam lee <[email protected]> wrote: >> >>>> >> >>>>> freemarker and gwt are just examples.. >> >>>>> >> >>>>> >> >>>>> Let's say I have a maven module that depends on: >> >>>>> >> >>>>> <dependency> >> >>>>> <groupId>mysql</groupId> >> >>>>> <artifactId>mysql-connector-java</artifactId> >> >>>>> <version>5.1.9</version> >> >>>>> </dependency> >> >>>>> >> >>>>> >> >>>>> To make the dependency work in the osgi bundle, I had to: >> >>>>> <Import-Package> >> >>>>> *;resolution:=optional >> >>>>> </Import-Package> >> >>>>> <Embed-Dependency> >> >>>>> mysql-connector-java;scope=compile|runtime >> >>>>> </Embed-Dependency> >> >>>>> >> >>>>> >> >>>>> I tried various combinations of maven-bundle-plugin.. but I only >> found the >> >>>>> above working. >> >>>>> >> >>>>> >> >>>>> My intuition is: >> >>>>> >> >>>>> 1. List <dependency>s that are not provided (<scope> isn't provided). >> >>>>> 2. List them under Embed-Dependency. >> >>>>> 3. Import-Package *;resolution:=optional >> >>>>> 4. If things don't work, add >> <Embed-Transitive>true</Embed-Transitive> >> >>>>> >> >>>>> >> >>>>> Or, like you mentioned, you can decipher >> >>>>> >> http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html >> >>>>> and look at the source code for maven-bundle-plugin. >> >>>>> >> >>>>> It's pretty simple. It's Java. (sarcasm). >> >>>>> >> >>>>> >> >>>>> >> >>>>> On Fri, Jun 10, 2011 at 3:47 PM, Shamik Bandopadhyay < >> [email protected]>wrote: >> >>>>> >> >>>>>> Sam, I just tried and it worked great. Just for my understanding, >> can >> >>>>>> you please explain how do decide to include freemarker and gwt and >> not >> >>>>>> the remaining package reference? >> >>>>>> >> >>>>>> On Fri, Jun 10, 2011 at 12:25 PM, sam lee <[email protected]> >> wrote: >> >>>>>>> Try it and see. Does it work? >> >>>>>>> >> >>>>>>> I wouldn't try to reason Java complexity, OSGi. >> >>>>>>> >> >>>>>>> On Fri, Jun 10, 2011 at 3:20 PM, <[email protected]> wrote: >> >>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> Shamik, >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> I completely understand how you feel about making bundles out of >> >>>>>>>> non-bundled .jar files. The standard answer is to contact the >> vendor and >> >>>>>>>> have them make bundles for you. However, this can take a while to >> >>>>>> accomplish >> >>>>>>>> and sometimes, especially for open-source .jar's, it may be >> difficult to >> >>>>>>>> get in touch with the folks who made the original .jar file. In >> >>>>>> addition to >> >>>>>>>> that method, there are a couple of quick and easy ways to make a >> osgi >> >>>>>> bundle >> >>>>>>>> out of a non-osgi .jar file. >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> First, you may want to consider using Karaf. This product can >> ride of >> >>>>>> top >> >>>>>>>> of felix (or equinox), and it has a number of helper functions >> that will >> >>>>>>>> make your job easier. >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> Second, when you install a non-bundled .jar file into Felix, try >> using >> >>>>>> the >> >>>>>>>> following syntax: >> >>>>>>>> >> >>>>>>>> osgi:install wrap:mvn:<artifactId>/<groupId>/version >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> I haven't tried this in Felix, but in Karaf over the top of Felix, >> this >> >>>>>>>> will automagically wrap your non-osgi bundle. "Wrapping" in the >> process >> >>>>>> of >> >>>>>>>> using a tool to add osgi-stuff into a non-osgi .jar file's >> MANIFEST.MF >> >>>>>>>> file. While this may not be the best approach for an operational >> >>>>>>>> environment, this will definately help you get your test stuff >> working. >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> To make a more operational-ready bundle, you can use the bnd tool >> to >> >>>>>> wrap >> >>>>>>>> your existing bundle. Bnd is a very powerful tool and is pretty >> well >> >>>>>>>> documented. Google it for more information. >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> Please let me know if this helps! >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> ----- Original Message ----- >> >>>>>>>> From: "Shamik Bandopadhyay" <[email protected]> >> >>>>>>>> To: [email protected] >> >>>>>>>> Sent: Friday, June 10, 2011 2:52:09 PM >> >>>>>>>> Subject: Re: Felix maven-bundle-plugin transitive dependency issue >> >>>>>>>> >> >>>>>>>> Hi, >> >>>>>>>> >> >>>>>>>> Thanks for your reply. Being a newbie, I'm finding a li'l hard to >> >>>>>>>> grasp the concept maybe. I agree, that embedding transitive >> dependency >> >>>>>>>> might not be the greatest idea since it contradicts OSGI >> fundamental. >> >>>>>>>> But at the sametime what bothers me is how do we address the >> non-osgi >> >>>>>>>> jars ? I can "n" number of jars in my project which maybe have >> other >> >>>>>>>> transitive dependencies. I don't see how efficient is the process >> of >> >>>>>>>> manually identifing them and make them OSGi enabled. I found the >> >>>>>>>> transitive dependency support comes handy in these cases. >> >>>>>>>> >> >>>>>>>> Unfortunately, I'm still not able to figure out how the >> >>>>>>>> <Embed-Transitive> property works for the maven-plugin-bundle. >> >>>>>>>> After,trying all possible combinations(so far), I haven't seen a >> >>>>>>>> single instance where a transitive jar got embedded in the bundle. >> >>>>>>>> >> >>>>>>>> I perhaps, need to do more reading to understand this. >> >>>>>>>> >> >>>>>>>> Can you pls share any pointers for best practises in this regard? >> >>>>>>>> >> >>>>>>>> Appreciate your help... >> >>>>>>>> >> >>>>>>>> -Thanks >> >>>>>>>> >> >>>>>>>> On Fri, Jun 10, 2011 at 11:41 AM, <[email protected]> >> wrote: >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> Shamik, >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> Embedding the transitive dependencies is one of those things that >> you >> >>>>>> can >> >>>>>>>> do in OSGi, but usually you shouldn't. The problem is that your >> bundle >> >>>>>> is >> >>>>>>>> likely not going to use most of the transitive dependencies. So, >> >>>>>> embedding >> >>>>>>>> them into your bundle can leave you with a much larger bundle than >> you >> >>>>>>>> really need with a bunch of "stuff" you don't need. Another >> problem >> >>>>>> that >> >>>>>>>> you'll see when embedding transitive dependencies is that you may >> run >> >>>>>> into a >> >>>>>>>> circumstance where a transitive dependency (especially for older >> stuff) >> >>>>>>>> isn't available any more. In this case, your build will break. >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> A better approach is to identify those bundles that you are >> actually >> >>>>>>>> going to use (which you've already done), and deploy those into >> OSGi >> >>>>>> before >> >>>>>>>> you deploy your taxonomy dao bundle. A rule of thumb that I use >> is, if >> >>>>>> a >> >>>>>>>> bundle is listed in the dependencies section of the pom, that >> bundle >> >>>>>> should >> >>>>>>>> be available within OSGi. >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> So, in short, try not embedding any dependencies in your bundle; >> >>>>>> instead, >> >>>>>>>> deploying all of the necessary bundles into OSGi first. If that >> doesn't >> >>>>>>>> work, only then should you try to embed. >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> Please let me know if that helps! >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> ----- Original Message ----- >> >>>>>>>>> From: "Shamik Bandopadhyay" <[email protected]> >> >>>>>>>>> To: [email protected] >> >>>>>>>>> Sent: Friday, June 10, 2011 1:56:54 PM >> >>>>>>>>> Subject: Felix maven-bundle-plugin transitive dependency issue >> >>>>>>>>> >> >>>>>>>>> Hi, >> >>>>>>>>> >> >>>>>>>>> I'm new to OSGI and trying to deploy my first application. I've a >> >>>>>>>>> spring dependency in my pom. While deploying I realized that >> Felix >> >>>>>>>>> runtime requires all transitive dependencies to install the >> bundle >> >>>>>>>>> properly. Since then, I'm sort of struggling to resolve this >> issue. >> >>>>>>>>> I've tried embedded-dependency and embedded-transitive options, >> but of >> >>>>>>>>> no luck. Here's my pom. >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> <project xmlns="http://maven.apache.org/POM/4.0.0"; >> >>>>>>>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; >> >>>>>>>>> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 >> >>>>>>>>> http://maven.apache.org/xsd/maven-4.0.0.xsd";> >> >>>>>>>>> <modelVersion>4.0.0</modelVersion> >> >>>>>>>>> <groupId>com.test</groupId> >> >>>>>>>>> <artifactId>taxonomydaobundle</artifactId> >> >>>>>>>>> <version>1.0.0</version> >> >>>>>>>>> <packaging>bundle</packaging> >> >>>>>>>>> <name>Taxonomy Dao Bundle</name> >> >>>>>>>>> <url>http://maven.apache.org</url> >> >>>>>>>>> <repositories> >> >>>>>>>>> <repository> >> >>>>>>>>> <id>fusesource</id> >> >>>>>>>>> <url>http://repo.fusesource.com/maven2</url> >> >>>>>>>>> <snapshots> >> >>>>>>>>> <enabled>false</enabled> >> >>>>>>>>> </snapshots> >> >>>>>>>>> <releases> >> >>>>>>>>> <enabled>true</enabled> >> >>>>>>>>> </releases> >> >>>>>>>>> </repository> >> >>>>>>>>> <repository> >> >>>>>>>>> <id>apache-public</id> >> >>>>>>>>> <url> >> https://repository.apache.org/content/groups/public/ >> >>>>>>>> </url> >> >>>>>>>>> <snapshots> >> >>>>>>>>> <enabled>true</enabled> >> >>>>>>>>> </snapshots> >> >>>>>>>>> <releases> >> >>>>>>>>> <enabled>true</enabled> >> >>>>>>>>> </releases> >> >>>>>>>>> </repository> >> >>>>>>>>> </repositories> >> >>>>>>>>> >> >>>>>>>>> <properties> >> >>>>>>>>> >> >>>>>>>> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> >> >>>>>>>>> </properties> >> >>>>>>>>> >> >>>>>>>>> <dependencies> >> >>>>>>>>> <dependency> >> >>>>>>>>> <groupId>com.test</groupId> >> >>>>>>>>> <artifactId>taxonomymodelbundle</artifactId> >> >>>>>>>>> <version>1.0.0</version> >> >>>>>>>>> <scope>compile</scope> >> >>>>>>>>> </dependency> >> >>>>>>>>> <dependency> >> >>>>>>>>> <groupId>org.springframework</groupId> >> >>>>>>>>> <artifactId>spring</artifactId> >> >>>>>>>>> <version>2.5.5</version> >> >>>>>>>>> </dependency> >> >>>>>>>>> <dependency> >> >>>>>>>>> <groupId>junit</groupId> >> >>>>>>>>> <artifactId>junit</artifactId> >> >>>>>>>>> <version>3.8.1</version> >> >>>>>>>>> <scope>test</scope> >> >>>>>>>>> </dependency> >> >>>>>>>>> </dependencies> >> >>>>>>>>> >> >>>>>>>>> <build> >> >>>>>>>>> <plugins> >> >>>>>>>>> <plugin> >> >>>>>>>>> <groupId>org.apache.felix</groupId> >> >>>>>>>>> <artifactId>maven-bundle-plugin</artifactId> >> >>>>>>>>> <version>2.0.1</version> >> >>>>>>>>> <extensions>true</extensions> >> >>>>>>>>> <configuration> >> >>>>>>>>> <instructions> >> >>>>>>>>> >> >>>>>>>> <Export-Package>com.test.taxonomy.api.*;version=1.0.0 >> >>>>>>>>> </Export-Package> >> >>>>>>>>> >> >>>>>>>>> <Import-Package>com.test.taxonomy.message.*;version=1.0.0, >> >>>>>>>>> * >> >>>>>>>>> </Import-Package> >> >>>>>>>>> >> >>>>>>>>> <Embed-Dependency>*;scope=compile|runtime</Embed-Dependency> >> >>>>>>>>> <Embed-Transitive>true</Embed-Transitive> >> >>>>>>>>> </instructions> >> >>>>>>>>> </configuration> >> >>>>>>>>> </plugin> >> >>>>>>>>> <plugin> >> >>>>>>>>> <groupId>org.apache.maven.plugins</groupId> >> >>>>>>>>> <artifactId>maven-compiler-plugin</artifactId> >> >>>>>>>>> <version>2.1</version> >> >>>>>>>>> <configuration> >> >>>>>>>>> <source>1.6</source> >> >>>>>>>>> <target>1.6</target> >> >>>>>>>>> </configuration> >> >>>>>>>>> </plugin> >> >>>>>>>>> </plugins> >> >>>>>>>>> </build> >> >>>>>>>>> </project> >> >>>>>>>>> >> >>>>>>>>> mvn install only embeds the direct dependency jars in the bundle. >> >>>>>>>>> When I try to install the bundle in Felix, its throwing import >> errors >> >>>>>>>>> as it's failing to resolve the dependencies. Here's a snippet : >> >>>>>>>>> >> >>>>>>>>> Imported Packages ERROR: bsh -- Cannot be resolved >> >>>>>>>>> ERROR: com.caucho.burlap.client -- Cannot be resolved >> >>>>>>>>> ERROR: com.caucho.burlap.io -- Cannot be resolved >> >>>>>>>>> ERROR: com.caucho.burlap.server -- Cannot be resolved >> >>>>>>>>> ERROR: com.caucho.hessian.client -- Cannot be resolved >> >>>>>>>>> ERROR: com.caucho.hessian.io -- Cannot be resolved >> >>>>>>>>> ERROR: com.caucho.hessian.server -- Cannot be resolved >> >>>>>>>>> ERROR: com.ibatis.common.util -- Cannot be resolved >> >>>>>>>>> ERROR: com.ibatis.common.xml -- Cannot be resolved >> >>>>>>>>> ERROR: com.ibatis.sqlmap.client -- Cannot be resolved >> >>>>>>>>> ERROR: com.ibatis.sqlmap.client.event -- Cannot be resolved >> >>>>>>>>> ERROR: com.ibatis.sqlmap.engine.builder.xml -- Cannot be resolved >> >>>>>>>>> ERROR: com.ibatis.sqlmap.engine.impl -- Cannot be resolved >> >>>>>>>>> ERROR: com.ibatis.sqlmap.engine.transaction -- Cannot be resolved >> >>>>>>>>> ERROR: com.ibatis.sqlmap.engine.transaction.external -- Cannot be >> >>>>>>>> resolved >> >>>>>>>>> ERROR: com.ibatis.sqlmap.engine.type -- Cannot be resolved >> >>>>>>>>> ERROR: com.ibm.wsspi.uow -- Cannot be resolved >> >>>>>>>>> ERROR: com.jamonapi -- Cannot be resolved >> >>>>>>>>> ERROR: com.mchange.v2.c3p0 -- Cannot be resolved >> >>>>>>>>> ERROR: com.sun.enterprise.loader -- Cannot be resolved and >> overwritten >> >>>>>>>>> by Boot Delegation >> >>>>>>>>> ERROR: com.sun.net.httpserver -- Cannot be resolved and >> overwritten by >> >>>>>>>>> Boot Delegation >> >>>>>>>>> ERROR: com.sun.rowset -- Cannot be resolved and overwritten by >> Boot >> >>>>>>>> Delegation >> >>>>>>>>> ERROR: commonj.timers -- Cannot be resolved >> >>>>>>>>> ERROR: commonj.work -- Cannot be resolved >> >>>>>>>>> ERROR: edu.emory.mathcs.backport.java.util.concurrent -- Cannot >> be >> >>>>>>>> resolved >> >>>>>>>>> ERROR: freemarker.cache -- Cannot be resolved >> >>>>>>>>> ERROR: freemarker.template -- Cannot be resolved >> >>>>>>>>> >> >>>>>>>>> My understanding was using >> <Embed-Transitive>true</Embed-Transitive> >> >>>>>>>>> will embed all transitive dependency jars in the bundle,but >> apparently >> >>>>>>>>> that's not been the case so far. >> >>>>>>>>> >> >>>>>>>>> I'll appreciate if someone can tell what's the right approach to >> >>>>>>>>> resolve this issue. >> >>>>>>>>> >> >>>>>>>>> -Thanks >> >>>>>>>>> >> >>>>>>>>> >> --------------------------------------------------------------------- >> >>>>>>>>> To unsubscribe, e-mail: [email protected] >> >>>>>>>>> For additional commands, e-mail: [email protected] >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>> >> >>>>>>>> >> --------------------------------------------------------------------- >> >>>>>>>> To unsubscribe, e-mail: [email protected] >> >>>>>>>> For additional commands, e-mail: [email protected] >> >>>>>>>> >> >>>>>>>> >> >>>>>>> >> >>>>>> >> >>>>>> >> --------------------------------------------------------------------- >> >>>>>> To unsubscribe, e-mail: [email protected] >> >>>>>> For additional commands, e-mail: [email protected] >> >>>>>> >> >>>>>> >> >>>> >> >>>> --------------------------------------------------------------------- >> >>>> To unsubscribe, e-mail: [email protected] >> >>>> For additional commands, e-mail: [email protected] >> >>>> >> >>>> >> >>> >> >>> --------------------------------------------------------------------- >> >>> To unsubscribe, e-mail: [email protected] >> >>> For additional commands, e-mail: [email protected] >> >>> >> >>> >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: [email protected] >> >> For additional commands, e-mail: [email protected] >> >> >> >> >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [email protected] >> > For additional commands, e-mail: [email protected] >> > >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
