I was not aware of wrap option in felix runtime....on a similar context, I did see the wrap / bundle option in maven-plugin-bundle. I tried using bundleall once but looks like the repository it's referring is lacking latest versions which results a failure in my case.
Thanks for the pointer, I'll take a look into pax-url-wrap in details On Fri, Jun 10, 2011 at 12:33 PM, Achim Nierbeck <[email protected]> wrote: > Well the wrap URL Handler works out of the box in Karaf > because pax-url-wrap is provided by standard. > > If you want to use the wrap URL Handler in your own > Felix/Equinox based OSGi runtime you need to install the > pax-url-wrap bundle also. > > regards, Achim > > Am 10.06.2011 21:20, schrieb [email protected]: >> >> 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]
