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]

Reply via email to