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  


Reply via email to