felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shamik Bandopadhyay <sham...@gmail.com>
Subject Re: Felix maven-bundle-plugin transitive dependency issue
Date Wed, 15 Jun 2011 15:30:03 GMT
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
<pererik.svensson@gmail.com> 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
> <justin@justinedelson.com>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 <shamikb@gmail.com>
>> 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
>> > <justin@justinedelson.com> wrote:
>> >> On Fri, Jun 10, 2011 at 6:34 PM, Shamik Bandopadhyay <shamikb@gmail.com>
>> 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
>> >>> <justin@justinedelson.com> 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 <skynare@gmail.com> 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 <
>> shamikb@gmail.com>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 <skynare@gmail.com>
>> 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, <mvangeertruy@comcast.net>
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" <shamikb@gmail.com>
>> >>>>>>>> To: users@felix.apache.org
>> >>>>>>>> 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,  <mvangeertruy@comcast.net>
>> 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" <shamikb@gmail.com>
>> >>>>>>>>> To: users@felix.apache.org
>> >>>>>>>>> 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: users-unsubscribe@felix.apache.org
>> >>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> ---------------------------------------------------------------------
>> >>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> >>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>
>> >>>>>>
>> >>>>>>
>> ---------------------------------------------------------------------
>> >>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> >>>>>> For additional commands, e-mail: users-help@felix.apache.org
>> >>>>>>
>> >>>>>>
>> >>>>
>> >>>> ---------------------------------------------------------------------
>> >>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> >>>> For additional commands, e-mail: users-help@felix.apache.org
>> >>>>
>> >>>>
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> >>> For additional commands, e-mail: users-help@felix.apache.org
>> >>>
>> >>>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> >> For additional commands, e-mail: users-help@felix.apache.org
>> >>
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> > For additional commands, e-mail: users-help@felix.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Mime
View raw message