You're playing with fire. Not providing all the dependencies at runtime that a library requires at compiling time is recipe for ClassDefNotFoundException which has plagued OSGi devs since the beginning of time.
> Subject: Re: managing OSGi Dependencies > From: pedro.doming...@ist.utl.pt > Date: Fri, 24 Oct 2014 23:14:41 +0100 > To: users@felix.apache.org; njbartl...@gmail.com > > Could you share your example project so that I could get a closer look? > > Thanks! > > On October 24, 2014 5:25:36 PM WEST, Neil Bartlett <njbartl...@gmail.com> > wrote: > >Further to this… I just created a Bndtools project to build a bundle > >containing your sample “SuchInterface” interface, plus the entire > >contents of the jscience.jar version 4.3.1 pulled from Maven Central. > >The only imported package was org.xml.sax, which as I said is provided > >by JavaSE. So there is no problem at all with this library. This job > >took about 2 minutes and it resolves just fine in Felix. > > > >I think your mistake is confusing build-time dependencies for runtime > >dependencies. This is why I recommend never to use Embed-Dependency: > >Maven only knows about build-time dependencies are they are MUCH more > >extensive than the runtime dependencies. > > > >Regards, > >Neil > > > > > >From: Neil Bartlett <njbartl...@gmail.com> > >Reply: Neil Bartlett <njbartl...@gmail.com>> > >Date: 24 October 2014 at 17:04:41 > >To: users@felix.apache.org <users@felix.apache.org>>, PedroD > ><pedro.doming...@ist.utl.pt>> > >Subject: Re: managing OSGi Dependencies > > > >The Conditional-Package instruction is documented > >here: http://bnd.bndtools.org/chapters/800-headers.html. There is no > >need to restrict yourself to reading only the maven-bundle-plugin > >documentation. All instruction and headers supported by bnd are > >supported by the Maven plugin, because the plugin passes them through. > > > >Also see my blog post about Conditional Package > >use: http://njbartlett.name/2014/05/26/static-linking.html > > > >I strongly recommend against using Embed-Dependency, and even more so > >Embed-Transitive! This is rather like using a nuclear ICBM to take > >potshots at a paper target. > > > >Regarding the Joda and SAX imports, Bndtools can tell you where these > >come from. Though if you use Conditional-Package, hopefully they won’t > >arise, unless you actually use them of course. The SAX import is not a > >problem because org.xml.sax is provided by JavaSE. Joda Convert is > >available as an OSGi bundle > >already: > >http://jpm4j.org/#!/p/sha/57C2432E54DC40F871F55295C676B22672713602//0.0.0 > > > >Regards > >Neil > > > > > >From: PedroD <pedro.doming...@ist.utl.pt> > >Reply: users@felix.apache.org <users@felix.apache.org>> > >Date: 24 October 2014 at 16:36:43 > >To: users@felix.apache.org <users@felix.apache.org>> > >Subject: Re: managing OSGi Dependencies > > > > > >Thanks > > > > > >On 24 Oct 2014, at 15:52, Neil Bartlett <njbartl...@gmail.com> wrote: > > > >Hello Pedro, > > > >To help you I’d first like to understand your current approach a bit > >better. You say you download these non-bundle dependencies and put them > >in the “bundle” directory until you get no more dependency errors. What > >effect does that have? Since they are not bundles, how does adding them > >to a directory help? > > > >As Christian points out, the problem is really with these libraries. > >Remember that Maven is also famous for downloading when you ask for the > >slightest thing. The reason for this is poor internal coherency which > >results in _fan out_. To explain: > > > >1. You depend on package org.foo which is part of the JAR file foolib. > >2. foolib contains 20 other packages *that you are not using* > >3. those 20 useless packages depend on five more JARs > >4. GOTO 1. > > > >Turning these JARs into bundles doesn’t help because they still have > >all those dependencies which all have to be resolved in order for OSGi > >to be happy. > > > >A better solution is to pull in only the packages that you really need. > >For example if you use the Conditional-Package instruction in bnd (also > >available as Conditional_Package in the maven-bundle-plugin) then you > >can create a bundle that includes only the packages that are referenced > >by your core code. This doesn’t always help because sometimes people > >have poor coherency even within their packages — general util packages > >are a common problem, just look at the dependencies from java.util for > >example — but it still easier to deal with than big messy JAR files. > > > >I hope that helps. > > > >Regards, > >Neil > > > > > >From: PedroD <pedro.doming...@ist.utl.pt> > >Reply: users@felix.apache.org <users@felix.apache.org>> > >Date: 24 October 2014 at 15:03:41 > >To: users@felix.apache.org <users@felix.apache.org>> > >Subject: managing OSGi Dependencies > > > >Greetings, > > > >I’m using Felix Framework for my OSGi project, but I’ve came across a > >severe problem concerning third party dependencies. > > > >I’m using eclipse and maven-bundle-plugin to generate my bundles from > >the sources and the MANIFEST.MF from the POM.XML file. So far so good. > >however when I have some third party dependency in my bundle, I find > >myself looking for an infinite list of JARs, which usually are not > >bundles, and putting them in my /bundle Felix directory until no more > >dependencies are missing. > > > >I call this process “Downloading the Internet for my OSGi application > >to work”. > > > >What am I doing wrong? Sure I must be doing something very wrong, > >because I can’t imagine anyone having a bundle A that depends on B, > >which then depends on C and D, and then those two will depend on > >several others and so on… > > > >What is the correct way to automate this? I would love to have one of > >the two solutions: > > > >1) Be able to create a massive JAR file with all of its dependencies > >embedded, but exporting only the packages I want, and, of corse, not > >importing any package. > > > >2) (My preferred solution) Having a way to get all my dependencies into > >individual JAR files that I can simply paste into the /bundle > >directory. > > > >I have found tools that do me this, but they only do it for direct (1st > >degree) dependencies, leaving transitive dependencies for me to solve > >manually. > > > >This problem is critical. The lack of such a tool hampers the usage of > >OSGi. I’ve searched and searched and searched, I’ve came across all the > >101 solutions such as PAX, bndtools, and friends, but they do not solve > >this issue… > > > >Please help me. > > > >Thanks! > >--------------------------------------------------------------------- > >To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > >For additional commands, e-mail: users-h...@felix.apache.org > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity.
