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.
