RE: [equinox-dev] Bundle Granularity?

[Thomas Watson <tjwatson@xxxxxxxxxx>]

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.

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.

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.

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