[news.eclipse.technology.equinox] Re: Best practices for dependency mana

[Stephan Herrmann <stephan@xxxxxxxxxxxxxxx>]

Hi,

> thanks. Yes, I know that using Import-package instead of Require-bundle
> is an OSGi best practice.
> My question is:  is it also an Eclipse best practice?

That sounds like a very good question.

IMHO, looking at some higher-level bundles in Eclipse shows that
Import-package is highly overrated in some discussions.
(read "higher-level" as: "not belonging to the core framework").

Why do I think so?

How often would you like to say things like:
"I need a package org.eclipse.jdt.core.compiler, but I don't know,
 which bundle should provide that package"? Or even: "The end-user
 needs to be able to choose a providing bundle"?
(There is only one option: org.eclipse.jdt.core)

OTOH, you might want to see: "What other modules does a bundle depend on?"
If you are asked to choose between browsing a list of 80 packages or
12 bundles, which sounds more like giving you the big picture
(aka: the architecture of your application)?

BTW: what exactly is meant by "Has a lower fan out"? In my understanding, 
a bundle that depends on 80 packages has a high fan in, compared to a bundle
depending on 12 bundles. But what is the fan out of a bundle?
(In my electronics classes I was taught that a high fan out is good, er?)

Why would one create components ("bundles") if these things cannot be used
to define the architecture?

Perhaps, Import-package comes from a level where "commodities" should
be integrated into an application. Everybody knows, how a HashMap works,
just give me any implementation, I don't care which. Fine.
Everyone knows how a Java-AST works? I don't care which one I will be
linked to? No!

Am I missing a point?

-- 
Stephan Herrmann