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> Reply: Pedro Domingues <pedro.doming...@ist.utl.pt>> Date: 24 October 2014 at 23:14:48 To: users@felix.apache.org <users@felix.apache.org>>, Neil Bartlett <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 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.