I have had a similar experience with utility bundles. Be sure to carefully
manage the prerequisites of a commonly used bundle. The trouble, as Jeff
correctly pointed out, is that they become dumping grounds for useful
types, and as a result their prerequisites (that is, the other bundles
upon which they depend) tend to grow. While having a large number of
prerequisites is not in itself a bad thing, it has a negative impact on
all those bundles higher on the stack that just want to use one or two
types in the utility bundle. In my case I saw a small 2 MB application
balloon to over 20 MB just because someone updated one of the packages I
imported, and consequently the bundle's prerequisites.
So, what's the solution? Ensure that your utility bundle remains highly
cohesive and does not become a grab-bag of unrelated helpers. Far better
to create multiple finely-grained, highly cohesive (and loosely coupled!)
bundles since this will result in a far more flexible bundle dependency
graph, be it at the cost of some complexity.
I've seen first hand the reaction people have to finely grained bundles,
and I've seen people merge bundles to make things "easier". The reality
is that when you merge bundles you are trading flexibility for simplicity
(less bundles). One day I'll write a packaging tool that merges bundles
for deployment, giving us the best of both worlds.
To that end, I would like to suggest using Import-Package rather than
Require-Bundle, since this gives you more flexibility regarding you
prerequisites. But let's save that debate for other thread.
Simon
From:
Peter Kriens <peter.kri...@aqute.biz>
To:
OSGi Developer Mail List <osgi-dev@mail.osgi.org>
Date:
12/01/2010 04:00 AM
Subject:
Re: [osgi-dev] Utility package as a bundle?
Sent by:
osgi-dev-boun...@mail.osgi.org
The problem with util bundles is that their transitive dependency has a
tendency to swell. That would be no problem if the util bundle was
cohesive but they rarely are. Example, I once debugged a case where about
20 Mb of external dependencies were dragged in because the developers used
one two line method in Apache commons collection.
For this reason, bnd has the Conditional-Package instruction. This
instruction is ignored while building the bundles but after the content is
set, it will match any imports against this instruction. Any matching
packages are copied to the bundle which is then reanalyzed until no more
matching imported packages are found. For example:
Private-Package: biz.aQute.whatever.impl.*
Conditional-Package: biz.aQute.util.*
Any imports from biz.aQute.util.* will automatically be included in your
bundle in your private are. That is, these utils will not be shared. Many
bundles can include the same package, one of the great advantages of OSGi
over other Java module systems.
Obviously this will create redundancy but it gives you less coupling,
there is a of course a trade off. However, it is binary redundancy, the
source code is still in one location.
I find this Conditional-Package to be extremely effective for specially
developed util jars. The model works best when the utils themselves are in
separate packages, this allows you to pick and choose and not pay for
unwanted dependencies.
Kind regards,
Peter Kriens
On 1 dec 2010, at 00:51, Wesley Silva wrote:
> Hi,
>
> I'm currently migrating an existing web application to OSGI. During the
> process I saw the utility package, where there are classes to manipulate
> things like date, strings, files, cryptography and so on. Almost all web
> applications in my company have this kind of package so I was wondering
if
> it was a good idea to turn it into a reused piece of software.
> So here is my question, is it a good idea to turn it into a bundle? If
so,
> how would this bundle look like? Would it publish some
> service thought interfaces or just export packages? Any suggestions?
>
> --
> Att,
> Wesley
> MSc Candidate in Software Engineering
> Specialist in Test Analisys (CIn/UFPE - Motorola)
> B.S. in Computer science - UFS
> Sun Certified Java Programmer
> Sun Certified Web Component Developer
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
