Ok, you said earlier that the jscience jar came from maven central repository.
I am having extreme difficulties importing your bndtools project to analyse the bundle it produces. According to http://bndtools.org/development.html#importing-into-eclipse I just need to import it as a regular project. After importing this is what I get on Eclipse: Because of this, I’ve later tried to create a new bndtools project and import the jscience-4.3.1.jar the same way you did, which according to http://bndtools.org/faq.html#how-can-i-depend-on-a-plain-jar-file-at-build-time there is no GUI for it. So I copied your file content: jscience: jscience-4.3.1.jar -buildpath: ${jscience}; version=file -runee: JavaSE-1.6 Private-Package: foo Include-Resource: @${jscience} -runfw: org.apache.felix.framework;version='[4.4.0,4.4.0]' javac.source: 1.6 javac.target: 1.6 (where can I see a full list of commands that I can use in .bnd files?) But I still have another problem; after compiling the bundle, the generated jar still wishes to import one package: Import-Package: org.xml.sax I’ve just tried this in felix and it seems to work fine. Felix already knows that package. What a luck! If that package was from another 3rd party library, I would be doomed to import it manually or check if maven central or similar for bundelized versions of it right? Thanks! This solves my issue for now. Regards, Pedro Domingues On 27 Oct 2014, at 14:22, PedroD <pedro.doming...@ist.utl.pt> wrote: > Was the jscience-4.3.1.jar file compiled by you? > > Regards, > Pedro Domingues > > > On 26 Oct 2014, at 17:01, Neil Bartlett <njbartl...@gmail.com> wrote: > >> Sorry I don't know anything about this error. >> >> The example I gave you didn't really have anything to do with gradle; that >> is just the default for bndtools projects. If you really want to use the >> maven plugin then I recommend taking the instructions from the bnd.bnd and >> using them in your pom.xml. >> >> Regards >> Neil >> >> -- >> Neil Bartlett >> Sent from a phone >> >> >> On Sunday, 26 October 2014 at 08:43, Pedro Domingues wrote: >> >>> Hello again Neil! >>> >>> I was trying to learn from your example in gradle, which I've never used >>> before, to try to map your configurations in maven (maven-bundle-plugin). >>> However when I import the project to eclipse as a gradle project and hit >>> the Build Model button, eclipse crashes without any mercy. >>> >>> screenshot: http://i.imgur.com/XwZXFeY.png >>> >>> Is this a simple (noob) error because I'm missing something very basic >>> and probably should go read more about gradle, or is something wierd >>> going on here? >>> >>> Thanks! >>> >>> Regards, >>> Pedro >>> >>> On 24/10/2014 23:46, Neil Bartlett wrote: >>>> Sure, here you go: https://github.com/njbartlett/jscience.example >>>> >>>> The only change to your code was to move it out of the default package. >>>> >>>> Regards, >>>> Neil >>>> >>>> >>>> From: Pedro Domingues <pedro.doming...@ist.utl.pt> >>>> <mailto:pedro.doming...@ist.utl.pt> >>>> Reply: Pedro Domingues <pedro.doming...@ist.utl.pt>> >>>> <mailto:pedro.doming...@ist.utl.pt> >>>> Date: 24 October 2014 at 23:14:48 >>>> To: users@felix.apache.org <users@felix.apache.org>> >>>> <mailto:users@felix.apache.org>, Neil Bartlett <njbartl...@gmail.com>> >>>> <mailto:njbartl...@gmail.com> >>>> Subject: Re: managing OSGi Dependencies >>>> >>>>> 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 th >>>>> ey >>>>> 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<http://jpm4j.org/#%21/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” director >>>>> y 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-plu >>>>> gin) >>>>> 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. >
