[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [equinox-dev] Bundle Granularity?
|
i think the current packaging granularity has much to do with the mantra
in eclipse "one bundle per project" or "one project per bundle" which
forces larger bundles in a subtle way. (it's just a naming thing. and
project is an old term with much impact baked into it from a semantic
point of view)
some more notes on
1. this convinience issue is mostly driven by the fact that usual java
packaging (jars) isn't really made to match with more advanced packaging
methodologies (as osgi is).
It's by the way a reason why handling osgi bundles with a static and
jar-driven maven is still pretty brittle (as peter kriens likes to say, too)
2+3: it's a difficult thing for equinox building/enforcing the next
specification on one hand and give a top-class osgi R4 implementation to
the community. this implementation should be exchangable to save the
open source mantra i think. If I understand Tom's "hook into it" this
isn't possible currently, is it?
Here we have a good example for the anti-forces "tight coupling" or
"redundancy" ..
kind regards,
Toni
Rick Litton schrieb:
Hi Tom,
Please refer to my responses below.
Rick Litton
------------------------------------------------------------------------
*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
------------------------------------------------------------------------
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
--
Toni Menzel
http://www.tonit.com
mailto:tonimenzel@xxxxxx
