Learning from Eclipse in order to design good OSGi applications?

[Stefan Zoerner <sz...@apache.org>]

Hi all,

sorry, if this is slightly off topic.

I try to figure out how to design an application which leverages the 
dynamics and extensibility of OSGi (general design principles).

Eclipse is always the first example people cite as an as a production 
ready, successful application based on OSGi. This may direct one to 
think that Eclipse uses OSGi best practices a lot, and copying Eclipse 
design decisions as patterns leads to a good design automatically.

I am quite sure that this does not hold true. For instance Eclipse uses 
dependencies between bundles a lot, although the preferred way to manage 
dependencies is via packages (as it is said in the spec and may online 
resources).

Do you know other examples for decisions made in Eclipse, which cannot 
be used as general design principle. Or the other way around: anything, 
that *can* be recommended.

Thanks in advance + Greetings from Hamburg,
     Stefan



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org

Re: Learning from Eclipse in order to design good OSGi applications?

[Marcel Offermans <ma...@luminis.nl>]

Hello Stefan,

On Apr 26, 2008, at 13:28 , Stefan Zoerner wrote:

> sorry, if this is slightly off topic. I try to figure out how to  
> design an application which leverages the dynamics and extensibility  
> of OSGi (general design principles).

I don't think it's much off topic.

> Eclipse is always the first example people cite as an as a  
> production ready, successful application based on OSGi. This may  
> direct one to think that Eclipse uses OSGi best practices a lot, and  
> copying Eclipse design decisions as patterns leads to a good design  
> automatically.

Eclipse is an example of an existing application that had a different  
"plugin model" that was migrated to OSGi. In fact, quite a few things  
in the R4 spec were added because they were used in Eclipse. To be  
fair to the Eclipse developers, they had to make quite a few trade- 
offs to remain compatible with earlier versions and not alienate a  
huge number of plugin writers. That has lead to decisions that might  
have been made differently if they had started from scratch.

> I am quite sure that this does not hold true. For instance Eclipse  
> uses dependencies between bundles a lot, although the preferred way  
> to manage dependencies is via packages (as it is said in the spec  
> and may online resources).

Yes, that is indeed one of these examples. Require bundle dependencies  
basically define dependencies in terms of "implementations" (if you  
look at bundles as implementations) instead of "interfaces" (which is  
what happens most of the time when you use the import/export model of  
defining dependencies.

> Do you know other examples for decisions made in Eclipse, which  
> cannot be used as general design principle. Or the other way around:  
> anything, that *can* be recommended.

One of the other big points of discussion is the Service vs Extension  
model. In fact on the Felix website you will find an example that  
implements a simple paint program using both methods. I have a strong  
preference for the service model because it has a cleaner life cycle  
and because that was the way OSGi was intended. Eclipse used  
extensions though because they argue it leads to faster startup.  
Startup for them matters enormously, since they have a lot of features  
that can be "loaded on demand". Extensions start faster basically  
because they don't lead to an "event storm" (associated with the life  
cycle model of services). On the other hand, I have the feeling that  
nobody really tried hard to optimize these events for startup time,  
and that there might be other ways to "not load everything at  
startup". For example, one could decide not to load a bundle at all  
until a user triggers some functionality, or to only install (and  
resolve) it, but not start. Anyway, I'm probably going to get trigger  
some opposing views with my responses here as this is a topic that's  
still under discussion.

In general, it's hard to recommend certain solutions, because a lot of  
decisions depend on actual requirements that often conflict.

An often used pattern is the whiteboard pattern. You can find that one  
on the OSGi site.

One thing to watch out for is not to go overboard on defining utility  
classes as bundles that export their classes. Especially if such  
utility classes are used all over the place. If lots of bundles  
actually depend on those classes, then updating them often equals  
almost a full restart of your application. Instead, embed utility  
classes in your bundles and use tooling that actually allows you to  
only embed things you actually use (if you care about minimizing code  
duplication).

I'm sure there are many other things people will add to this list. :)

Greetings, Marcel


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org