felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard S. Hall <he...@ungoverned.org>
Subject Re: When and how to adjust org.osgi.framework.system.packages
Date Mon, 11 Dec 2006 02:56:02 GMT
On Dec 10, 2006, at 9:38 PM, Steven E. Harris wrote:

> "Richard S. Hall" <heavy@ungoverned.org> writes:
>> You can put the whole log bundle on the class path, I don't care, but
>> you should still only export the log package from the system
>> bundle. Then you can install the log bundle and update, etc. as a
>> normal bundle.
>> Frankly, it puzzles me why it seems to be such a big concern to take
>> open source files and put them in your own project. This a valid form
>> of re-use.
> Well, much of the allure of OSGi is its ability to build an
> application that does not rely on a specific set of dependencies being
> available, with the ability to update or swap out bundles as things
> evolve. I expect the Felix code to evolve, and it's easier to
> incorporate its evolution when we treat it as a set of opaque bundles,
> as opposed to having to keep some of its files under my own source
> control system as concrete dependencies.

Maybe so, but we are not talking about bundles and their dependencies 
here. We are talking about sharing classes between the host application 
which is external to the framework and bundles which are internal to 
the framework. The spec does not cover this case. If you build your 
entire application as a set of bundles, then you won't have this issue, 
but if you need a host application that is external to the framework, 
then you will.

>> This has nothing to do with "extracting a subset out of the Felix
>> log JAR". We are talking about open source interface files that the
>> OSGi Alliance makes available for use in your projects.
> Perhaps it would make more sense to get these interface files directly
> from OSGi, as these files are just one facet of the OSGi
> specification, which we expect to be stable and consistent among any
> framework we rely on.

I guess I don't see the point. You need the interfaces. You can grab 
them from where ever you want. If you are talking about grabbing the 
source, then Felix' compendium bundle is as good as the OSGi JAR, since 
that is where the source came from. Or if your concern is getting them 
from the Felix bundle binary because it is not the definitive source, I 
guess it makes some sense, but it appears to be overly cautious since 
the source for Felix' compendium bundle is freely available for 

In the end, you have to do what you feel comfortable with, but to me is 
seems to be much ado about nothing.

>> From my point of view, re-using these files in your own project is
>> not a big deal. They are interface classes after all, not
>> implementation classes.
> Yes, I see.
> My hesitation comes from having worked with the coarse-grained
> dependency view that Maven brings. I know you've (or someone else has)
> written here recently that you don't feel too sympathetic to the
> Maven JARs-as-indivisible-units-of-dependency view.
> I want to keep as much of my application as easy to update as
> possible. Obviously depending on bundles-as-bundles is a local
> maximum. Having my main application depend on things provided in
> bundles is possible, but not as easy as bundle-to-bundle dependency.
> I was just asking about this here to feel around if this impression is
> true, to see if I was stepping into hazardous territory. It will take
> more experimenting for my view to settle.

This really has nothing to do with 
"JARs-as-indivisible-units-of-dependency view", it has to do with 
what's internal to the framework vs what is external to the framework.

I may be mistaken, but I don't know of any framework that makes host 
application-to-bundle dependencies easy (or even possible). I have 
given thought to this topic, but it is not straightforward. It is 
actually something for which I have wanted to find a solution but have 
never found the time to work it (my thought is virtual bundles). Maybe 
I will in the future. However, for the time being, as long as you want 
to mix external and internal code, you are going to have to do it 
through the class path or through reflection as far as I can see.

Think of it this way, since your host application is not a bundle, it 
doesn't benefit from the hot deploy/modularity features of the 
framework. If your host application uses the OSGi log API, then it 
effectively makes that API part of your host application, which means 
that it too no longer falls under the auspices of the framework. That's 
just the way it is.

-> richard

View raw message