Again, with Conditional-Package the assumption is that each util class has its
own package. So bnd can include packages and only drag in the dependencies of
that package. Many Apache commons unfortunately mix many utils in a single
package.
Kind regards,
Peter Kriens
On 1 dec 2010, at 18:46, Tommy M. McGuire wrote:
> One further cautionary note: watch the "uses" constraints on the packages you
> export. bnd in particular has to be conservative about what it includes, so
> you may find it necessary to deal with the constraints manually. Otherwise,
> one Import-Package can tie your bundle to many other things that may not
> strictly be necessary.
>
> I'm chopping up my own big-hunk o' utils at the moment....
>
> On 11/30/2010 08:02 PM, Jeff McAffer wrote:
>> What Richard said plus a cautionary note. These sorts of "common" or
>> "util" bundles have a way of growing and taking on a life of their own.
>> People have a tendency to use them as dumping grounds for "that little
>> class that everyone will want" etc. To help mitigate this tendency:
>> - clearly define the scope of what goes in the bundle and what does not
>> - maintain high coherence in your package namespace (don't just put all
>> the things in a "utils" package)
>> - encourage people to use Import-Package to enable shipping various
>> shapes of "util" bundle
>>
>> From an organizational point of view, you likely want to also establish
>> what group/team/person is responsible for the content of the bundle(s).
>> Topics like content regulation, maintenance, ...
>>
>> Jeff
>>
>>
>> On 2010-11-30, at 7:32 PM, Richard S. Hall wrote:
>>
>>> A simple library bundle would likely just export the packages it
>>> wishes to share.
>>>
>>> Not all bundles need to provide services. Services decouple bundles
>>> from implementation details, enabling multiple providers and dynamism.
>>>
>>> Package sharing is another valid form of bundle collaboration, it is
>>> just a little less flexible. That doesn't mean it should be avoided
>>> completely, nor can it.
>>>
>>> Now if you thought you might have multiple implementations of these
>>> utilities that you wanted to swap out dynamically, then defining
>>> services might make sense. But even at the package level you can have
>>> multiple implementations, it only means that swapping out
>>> implementations is slightly more traumatic on your system.
>>>
>>> -> richard
>>>
>>> On 11/30/10 6:51 PM, 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?
>
>
>
> --
> Tommy M. McGuire
> mcgu...@crsr.net
> _______________________________________________
> 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
