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 <[email protected]> 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 <[email protected]> >Reply: Neil Bartlett <[email protected]>> >Date: 24 October 2014 at 17:04:41 >To: [email protected] <[email protected]>>, PedroD ><[email protected]>> >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 <[email protected]> >Reply: [email protected] <[email protected]>> >Date: 24 October 2014 at 16:36:43 >To: [email protected] <[email protected]>> >Subject: Re: managing OSGi Dependencies > > >Thanks > > >On 24 Oct 2014, at 15:52, Neil Bartlett <[email protected]> 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 <[email protected]> >Reply: [email protected] <[email protected]>> >Date: 24 October 2014 at 15:03:41 >To: [email protected] <[email protected]>> >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: [email protected] >For additional commands, e-mail: [email protected] -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
