You're shipping the binary, not the source. So the only thing you waste are a
few bits. In my experience,you actually save megabytes because you break the
transitive dependency.
Note that Conditional-Package does NOT create source redundancy. Any bug that
creeps up and fixed is automatically fixed next time the bundle is build (and
tested). Really, the problem you sketch is non-existent. On the contrary, in my
experience it increases robustness. Instead of finding the new util jar in
runtime you test the bundle using the Conditional-Package with the exact
version you'll deploy. So if project A uses Conditional-Package to include
Bundle U, then the build system will automatically create a new version of A
when you make changes to U. Again, it works very well in practice.
You point out a subtle difference between a util and an interoperability
standard. Utility classes with Conditional Package must not appear in the
public API of the bundle because each bundle has its own binary copy. A util is
supposed to do some repetitive work, not provide important abstractions. Those
are services.
Kind regards,
Peter Kriens
On 1 dec 2010, at 16:23, Jeff McAffer wrote:
> It may be the only way but I have to say I'd be concerned about maintenance
> if we ended up shipping 100 copies of the same util classes. Historically in
> Eclipse we have had a number of widely used utility classes that had
> subtle/complex behaviour (e.g., StringMatcher, Path, ...). The sort of thing
> that you think should be easy but turn out to be hard. Inevitably bugs crop
> up or tweaks are done. If every user of those classes had their own copy,
> deploying changes would be a nightmare.
>
> In the end there is a balance in there somewhere.
>
> Jeff
>
> On 2010-12-01, at 10:16 AM, Marcel Offermans wrote:
>
>> A smarter bundle tool should be able to eliminate unused utility classes
>> from such bundles, greatly reducing their size. But making bundles more fine
>> grained is definitely a good tip too.
>>
>> Greetings, Marcel
>>
>>
>> On 1 Dec 2010, at 15:58 , Simon J Archer wrote:
>>
>>>
>>> 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
>>
>> _______________________________________________
>> 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
