Home » Eclipse Projects » Equinox » Required Plugins Considered Harmful
| |
| Re: Required Plugins Considered Harmful [message #81244 is a reply to message #81214] |
Wed, 17 January 2007 06:55   |
|
JOHN J. BARTON wrote:
> Is it true?
Required-Bundle (aka. require plug-in) is part of what made Eclipse long
before Eclipse was running on OSGi. It exists for the sake of backwards
compatibility and (of course) simplicity.
The dynamics comes together with extension points and extensions.
Usually you require a bundle that defines the contract and the extension
point. You then ask for the extensions without knowing which bundles
(plug-ins) provide the implementation.
Cu, Gunnar
--
Gunnar Wagenknecht
gunnar@wagenknecht.org
http://wagenknecht.org/
|
|
|
| Re: Required Plugins Considered Harmful [message #81258 is a reply to message #81214] |
Wed, 17 January 2007 10:51 |
Eclipse User |
|
|
|
Originally posted by: alex_blewitt.yahoo.com
IMNSHO, the bundle class-path isn't particularly relevant. The two models are either import/export package, or require bundle.
The bundle classpath is something which just lays out how bundles should be realised; in fact, I'd argue that it's bad practice to have jars-in-jars in general, and so that you don't explicitly want to do that, especially if you are using them for public API/internal implementation separation. At run-time, OSGi environments like Eclipse will need to extract your jar-from-a-jar into a separate temp area (i.e. storing it twice on the file system) thus making it (marginally) slower to use.
Anyhoo ... the difference between the two is that import package allows you to grab packages from whoever exports them, whereas with requrise bundle, you're tied down to a single provider. An example is the IBM ICU classes (that deal with Unicode support). There's two bundles; the main one (3Mb) and a 'lite' version of a matter of a few kilobytes. Both export the same package, and code that depends on it imports the same package; so you can swap one bundle for another at deployment time, depending on whether you need 'full' unicode support (or have deployment space issues).
You couldn't do that with requires-bundle, unless both bundles had the same name (in which case, how would you tell the difference between them ...)
With both import package and requires bundle, you can mix up implementation and interface if you try; that's why you either don't export the package, or if you do, mark it as internal.
Both bundles and packages can have versioned constraints for dependencies.
I'd aim for always having a Bundle-ClassPath of '.' regardless of which import/requires model you choose.
Alex.
|
|
| | |
| Re: Required Plugins Considered Harmful [message #81349 is a reply to message #81258] |
Wed, 17 January 2007 21:32 |
 John J. Barton
Messages: 311
Registered: July 2009 |
Senior Member |
|
|
Alex Blewitt wrote:
> IMNSHO, the bundle class-path isn't particularly relevant. The two models are either import/export package, or require bundle.
Yes, I know what you mean by experience with the Eclipse plugin.xml
tool, but according to the OSGi class loading algorithm required bundle
and bundle class path are very similar. How much difference would there
be if you put a bundle jar file on the bundle class path rather than
listing the same bundle under Required Bundles?
>
> The bundle classpath is something which just lays out how bundles should be realised; in fact, I'd argue that it's bad practice to have jars-in-jars in general, and so that you don't explicitly want to do that, especially if you are using them for public API/internal implementation separation. At run-time, OSGi environments like Eclipse will need to extract your jar-from-a-jar into a separate temp area (i.e. storing it twice on the file system) thus making it (marginally) slower to use.
>
> Anyhoo ... the difference between the two is that import package allows you to grab packages from whoever exports them, whereas with requrise bundle, you're tied down to a single provider. An example is the IBM ICU classes (that deal with Unicode support). There's two bundles; the main one (3Mb) and a 'lite' version of a matter of a few kilobytes. Both export the same package, and code that depends on it imports the same package; so you can swap one bundle for another at deployment time, depending on whether you need 'full' unicode support (or have deployment space issues).
>
> You couldn't do that with requires-bundle, unless both bundles had the same name (in which case, how would you tell the difference between them ...)
>
> With both import package and requires bundle, you can mix up implementation and interface if you try; that's why you either don't export the package, or if you do, mark it as internal.
>
> Both bundles and packages can have versioned constraints for dependencies.
>
> I'd aim for always having a Bundle-ClassPath of '.' regardless of which import/requires model you choose.
>
> Alex.
|
|
|
| Re: Required Plugins Considered Harmful [message #81392 is a reply to message #81349] |
Thu, 18 January 2007 03:34 |
| Eclipse User |
|
|
|
Originally posted by: alex_blewitt.yahoo.com
> Yes, I know what you mean by experience with the Eclipse plugin.xml
> tool, but according to the OSGi class loading algorithm required bundle
> and bundle class path are very similar. How much difference would there
> be if you put a bundle jar file on the bundle class path rather than
> listing the same bundle under Required Bundles?
If you have a .jar in a bundle, then you have an even stricter tie than with Require-Bundle. For example, you can't push out an update to one of the Jars in a Bundle easily, and if they evolve at different speeds from 'your' code then you'll find yourself updating your bundle and re-sending the same libraries (or vice versa) more often than you need to.
The bundle relationship, on the other hand, is versioned and dynamic. So I can run with a dependency on Xerces 2.5.1, and then update the Xerces bundle to 2.5.2 dynamically without needing to send any updates to my code.
Lastly, in a .jar, then all of that jar is visible to the bundle (both internal and API). If you have it in a bundle, then that need not be the case.
Taken to its illogical extreme, if you thought the Require-Bundle and internal .jar were the same, why was (say) Eclipse 2.1 not shipped as just a single Jar with many thousands of Jars in it? Modularity and reusability are essentially the keys, which are orthogonal to the way that a Class or Resource request are serviced by the OSGi layer.
Alex.
|
|
|
| Re: Required Plugins Considered Harmful [message #81405 is a reply to message #81335] |
Thu, 18 January 2007 06:25 |
|
JOHN J. BARTON wrote:
> But the binding of the
> extension to the extension point is "static" or at least hard to
> reverse at run time.
Absolutely not, extensions are added and removed from the extension
registry as bundles are added/removed/reloaded. It's very dynamic.
> 1) How to clearly specify the common pool of class packages seen by
> the equinox service framework?
You need to explicitly export the packages. I think that's pretty much
OSGi-ish. ;)
> 2) How to create flexible plugin architectures that support runtime
> bundle load/unload?
It's your choice. I'm a long time Eclipse hacker and I use extension
points a lot. But that's also because I know that my solution will
always (re)use as much Eclipse technology as available. But that doesn't
mean I'm not using OSGi services as well. It really depends on your use
cases and your preferences.
Cu, Gunnar
--
Gunnar Wagenknecht
gunnar@wagenknecht.org
http://wagenknecht.org/
|
|
|
| Re: Required Plugins Considered Harmful [message #81546 is a reply to message #81392] |
Fri, 19 January 2007 18:38 |
John J. Barton
Messages: 311
Registered: July 2009 |
Senior Member |
|
|
Thanks Alex, but I'm just not getting it. I don't understand this
phrase: 'If you have a .jar in a bundle...'. I guess you mean that
you are comparing two cases:
1) library B.jar on bundle A class path
to
2) bundle B on RequiredBundle for A
If so I understand you comment since B.jar does not have a MANIFEST.MF
But bundle B is also a jar file. So I was comparing
1) bundle B jar file on bundle A class path
to
2) bundle B jar file on bundle A RequiredBundle.
The spec makes these cases the same for class loading.
Maybe there are ways in which RequiredBundle differs other than
class loading?
John.
Alex Blewitt wrote:
>>Yes, I know what you mean by experience with the Eclipse plugin.xml
>>tool, but according to the OSGi class loading algorithm required bundle
>>and bundle class path are very similar. How much difference would there
>>be if you put a bundle jar file on the bundle class path rather than
>>listing the same bundle under Required Bundles?
>
>
> If you have a .jar in a bundle, then you have an even stricter tie than with Require-Bundle. For example, you can't push out an update to one of the Jars in a Bundle easily, and if they evolve at different speeds from 'your' code then you'll find yourself updating your bundle and re-sending the same libraries (or vice versa) more often than you need to.
>
> The bundle relationship, on the other hand, is versioned and dynamic. So I can run with a dependency on Xerces 2.5.1, and then update the Xerces bundle to 2.5.2 dynamically without needing to send any updates to my code.
>
> Lastly, in a .jar, then all of that jar is visible to the bundle (both internal and API). If you have it in a bundle, then that need not be the case.
>
> Taken to its illogical extreme, if you thought the Require-Bundle and internal .jar were the same, why was (say) Eclipse 2.1 not shipped as just a single Jar with many thousands of Jars in it? Modularity and reusability are essentially the keys, which are orthogonal to the way that a Class or Resource request are serviced by the OSGi layer.
>
> Alex.
|
|
|
| Re: Required Plugins Considered Harmful [message #81603 is a reply to message #81546] |
Sat, 20 January 2007 05:52 |
| Eclipse User |
|
|
|
Originally posted by: alex_blewitt.yahoo.com
The Manifest.MF contains the following entry:
Bundle-Classpath: .
This means 'all classes in the bundle are included'
You cannot have:
Bundle-Classpath: ../something/else
because it's relative to the contents of the bundle (after export). So there's no 'parent' to navigate up.
Bundle-Classpath: .,some.jar
means classes in the current bundle (.) as well as those classes shipped in the some.jar are available to this bundle. In this case, regardless of whether some.jar contains any extra details in the manifest, it's not a separate bundle; it's just a Jar file that happens to be contained in a bundle. From an efficiency point of view, this is a bad thing and should be avoided.
In all these cases, we're just looking at a single bundle. There's no concept of 'bundle A being on bundle B's classpath'.
OSGi wires up bundles at run-time by satisfying either Import-Package or Require-Bundle constraints. From a class resolution point of view, there's not much difference between them; the differences are more to do with management and choice of substitution with other implementations.
Alex.
|
|
|
Goto Forum:
Current Time: Sat May 11 10:03:51 GMT 2024
Powered by FUDForum. Page generated in 0.05712 seconds |
] 
Search
Help
Register
Login
Home
