Hi Tom,
Please refer to my responses below.
From: equinox-dev-bounces@xxxxxxxxxxx
[mailto:equinox-dev-bounces@xxxxxxxxxxx] On
Behalf Of Thomas Watson
Sent: Thursday, February 01, 2007
10:09 AM
To: Equinox development mailing
list
Subject: RE: [equinox-dev] Bundle
Granularity?
There are a few reasons we package the core org.osgi
classes in the framework implementation (org.eclipse.osgi)
1)
Packaging convenience. Having all the org.osgi.* classes packaged
directly in the framework implementation reduces the amount jars you need to
find and place on the classpath of the framework.
-> I was assuming that the osgi
bundles will be auto-started and that the required packages are exported which
can then be imported by org.eclipse.osgi. I haven’t actually done
this but I think it should work.
2)
Technically we need to modify some of the classes provided by the OSGi Alliance
to hook into our implementation. For example, FrameworkUtil,
AdminPermission and BundleSignerCondition.
-> Can
we get away with just extending the osgi interfaces? I guess I find
changing someone else’s framework classes/interfaces unappealing.
3)
Working on future reference implementations for the OSGi Alliance. We
need the ability to modify the API with enhancements that will become available
in future public OSGi specifications. For example, we are currently
working on the Reference Implementation for OSGi R4.1 which introduces a small
number new methods.
->
Personally, I think that this is even an important consideration. Switching
OSGi R4 bundles with OSGi R4.1 ones will be a “snap” (hopefully)
when they become available. Like everyone else, I suppose OSGi will also
provide maintenance or versioned releases to fix defects, etc. It would
be expedient to simply switch to those versioned ones without having to release
an Equinox distro in response. In this sense, tight coupling has its
disadvantages in my view.
Tom
|
"Rick Litton"
<Rick.Litton@xxxxxxxxxxxxxxx>
Sent
by: equinox-dev-bounces@xxxxxxxxxxx
02/01/2007 11:35 AM
|
Please
respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
|
|
|
To
|
"Equinox development mailing list"
<equinox-dev@xxxxxxxxxxx>
|
|
cc
|
|
|
Subject
|
RE: [equinox-dev] Bundle Granularity?
|
|
Jeff McAffer wrote:
>
In Eclipse we have continually refactored bundles. In 3.2 the Runtime
bundle was split into 5 or 6 bundles. In 3.0 the UI was split into 7. This
was driven by actual usecases and requirements. It turns out that one of
the key factors in the simplicity/difficulty of doing that refactoring was Java
package naming! We got hosed a couple of times by lumping fundamentally
unrelated things together in the same Java package. org.eclipse.core.runtme
for example. When we went to refactor we ended up needing to split the
same package over multiple bundles. This is possible but can be ugly and
in the end results in some unfortunate legacy naming glitches.
On the subject of refactoring, perhaps you would consider
removing the org.osgi.* packages inside org.eclipse.osgi bundle and instead use
the core and compendium bundles from OSGi directly. Not sure if there is
any “legal” or technical impediment to this approach.
Rick Litton
From:
equinox-dev-bounces@xxxxxxxxxxx [mailto:equinox-dev-bounces@xxxxxxxxxxx] On Behalf Of Jeff McAffer
Sent: Wednesday, January 31, 2007 5:40 PM
To: Equinox development mailing list
Subject: Re: [equinox-dev] Bundle Granularity?
My 2c
I'm in agreement on bundling making sense from a code/reuse/componentization
point of view. We use a simple rule.
"If two bundles will never be shipped separately,
combine them"
Your definition of "never" may change over time but that's ok. What
doesn't change? In Eclipse we have continually refactored bundles. In
3.2 the Runtime bundle was split into 5 or 6 bundles. In 3.0 the UI was
split into 7. This was driven by actual usecases and requirements. It
turns out that one of the key factors in the simplicity/difficulty of doing
that refactoring was Java package naming! We got hosed a couple of times
by lumping fundamentally unrelated things together in the same Java package. org.eclipse.core.runtme
for example. When we went to refactor we ended up needing to split the
same package over multiple bundles. This is possible but can be ugly and
in the end results in some unfortunate legacy naming glitches.
Anyway, this is distinct from discussions of extensions vs services etc. I
actually disagree with Simon that this should impact what you do. Yes
there is one extension point definer but the extension point definer is the
moral equivalent the bundle that defines a service *interface* not the
instances of the service. These are the people who define the contract. In
OSGi typically there is only one of a given service interface. There is
no particular need to pair extension use with Require-Bundle use. Extension
points can be moved between bundles as can service interface definitions so
indeed it could be seen as a programming/design error to depend on extension
point origin.
Jeff
|
Simon J Archer
<sarcher@xxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx
01/31/2007 10:56 AM
|
Please
respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
|
|
|
To
|
Equinox development mailing list
<equinox-dev@xxxxxxxxxxx>
|
|
cc
|
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>,
equinox-dev-bounces@xxxxxxxxxxx
|
|
Subject
|
Re: [equinox-dev] Bundle Granularity?
|
|
Craig
I wanted to echo Oleg's points. Deciding whether to have one bundle or
two is a very similar decision to whether you should have one class or two. The
most important thing, in my opinion, is to model the problem appropriately,
rather than trying to create less bundles in the hope of some performance
gains. The reality is that fine grained bundles are typically more
flexible and more reusable than coarse grained bundles, but they are also more
complicated to understand.
Something that I have observed is that people building bundles for the Eclipse
platform tend to build less fine grained bundles than people building bundles
for some other OSGi/Equinox application. One reason for this, I believe,
is Eclipse extension points: While an extension point allows you to achieve
similar things to an OSGi service, there is only ever exactly one provider of a
particular Eclipse extension point, whereas there can be many providers of a
particular OSGi service. Eclipse bundles are typically not composed of
OSGi services, although that is not to say they cannot be used. Instead
the Eclipse platform tends to favor extension points. Reasons for this
include Eclipse's necessity for laziness, and another is Eclipse's origins and
life before OSGi.
I tend to find that when I'm building bundles for Eclipse I use the
Require-Bundle manifest header to describe my bundle's dependency on a
particular bundle (that often declares an extension point to which I wish
contribute), whereas when I am building bundles for OSGi/Equinox I use the
Import-Package manifest header. Require-Bundle encourages coarse grained
dependencies, whereas Import-Package encourages fine grained dependencies.
I would suggest leaning towards fine grained bundles rather than coarse, since
merging bundles is far easier than splitting bundles.
I hope this helps,
Simon
|
Oleg Besedin
<obesedin@xxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx
01/31/2007 10:20 AM
|
Please
respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
|
|
|
To
|
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
|
|
cc
|
|
|
Subject
|
Re: [equinox-dev] Bundle Granularity?
|
|
Hi Craig,
Back when we were doing the runtime split for 3.2 I did some testing on how
having code in separate plugins vs. one plugin impacts performance.
Performance-wise having code in separate bundles had small impact on startup
time. To be more concrete, having an extra bundle on WinXP 2GHz 2Gb adds about
1ms to the "warm" startup time. The impact is more significant for
the "cold" startup, but those are very hard to quanitfy. My guess
would be 2 - 5 ms, but it is just a guess (variability of cold startups is too
high).
What did seem to impact startup performance was the amount of code that had to
be loaded. More features -> more code -> slower startup. Again, to put
some numbers, on the system above having a few extra classes loaded in
activators added 28 ms to the startup sime.
There was no detectable impact on the runtime performance. Memory impact was
rather hard to measure reliable; from the common sense there should be very
little cost memory-wise. As for threads, there is no relationship between the
number of threads and number of bundles.
In my opinion, granularity of bundles should be determined more by things like:
- business considerations;
- need to keeping things compartmentalized / reusable;
- separation of work between developers / teams.
>From a technical side there is a small cost associated with having extra
bundles, but it seems to be rather small. That said please don't create a
bundle per class :-)
Sincerely,
Oleg Besedin
|
Craig Setera
<craigjunk@xxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx
01/31/2007 08:00 AM
|
Please
respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
|
|
|
To
|
equinox-dev@xxxxxxxxxxx
|
|
cc
|
|
|
Subject
|
[equinox-dev] Bundle Granularity?
|
|
I'm wondering if there are any rules of thumb in terms of the
granularity of bundles? What are the advantages and disadvantages of
having fine grained bundles versus coarser grained bundles? For
instance, what is the average cost of a bundle in terms of:
- Memory overhead?
- Classloader lookup times?
- Threads in the system?
- Other overhead?
The positive things I can think of include the ability for the system to
lazily load only the bundles that are actually necessary. What are the
other advantages of finer grained bundles?
Thanks for any insights you can provide.
Craig
PS - I'm primarily talking about bundles in the context of the Eclipse
platform rather than at the Equinox framework level.
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
