| Best practices for dependency management [message #91676] |
Sat, 07 July 2007 06:11  |
Eclipse User |
|
|
|
Originally posted by: amottadelli_NO_SPAM.it.ibm.com
In Eclipse/OSGi plugin dependencies can be expressed in two different
ways: required plugins or import-package.
For our project (a rather large application), we are discussing the
relative merits of the two approaches.
Import-package looks superior as it allows for better maintainability,
but it appears that some Eclipse mechanisms depend on the Require-bundle
approach (buddy class loading, Extension points).
Can anybody provide any thoughts or pointers on the matter?
Many thanks,
A.Mottadelli
|
|
|
|
|
| Re: Best practices for dependency management [message #91791 is a reply to message #91676] |
Mon, 09 July 2007 14:15  |
| Eclipse User |
|
|
|
Originally posted by: lamont_gilbert.rigidsoftware.com
On Sat, 07 Jul 2007 08:11:21 +0200, Alessandro Mottadelli wrote:
> In Eclipse/OSGi plugin dependencies can be expressed in two different
> ways: required plugins or import-package.
>
> For our project (a rather large application), we are discussing the
> relative merits of the two approaches.
>
> Import-package looks superior as it allows for better maintainability,
> but it appears that some Eclipse mechanisms depend on the Require-bundle
> approach (buddy class loading, Extension points).
>
> Can anybody provide any thoughts or pointers on the matter?
>
> Many thanks,
>
> A.Mottadelli
I use required plugins as I want to be sure I know where the package came
from. You can use import-package when you dont really care where the
package comes from. But when you are taking code from who knows where,
you need to program very defensively.
So for packages under my control I have them in a plugin and use required
plugins. For other packages such as log4j, I MAY use import-packages.
Mostly though I prefer required-plugins as when you start versioning
things its easier to manage the version your program is using.
CLG
|
|
|
| Re: Best practices for dependency management [message #91857 is a reply to message #91707] |
Mon, 09 July 2007 21:17 |
 Stephan Herrmann
Messages: 1853
Registered: July 2009 |
Senior Member |
|
|
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
|
|
|
Powered by
FUDForum. Page generated in 0.03477 seconds
] 
Search
Help
Register
Login
Home
