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 Sat, 11 Jun 2011 21:41:43 GMT
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


Mime
View raw message