I'd like one additional piece of advice to the good suggestions of Richard and Jeff. Such utility bundles tend to be used by a lot of bundles. That means that if you ever want to update such a bundle, a lot of other bundles will be affected by that. In extreme cases, this could mean that your whole application might "stop and start" on such an update. Therefore, I often recommend a different approach, which is to actually embed the utility classes you use in the bundles that use it. That way, at runtime, you have less coupling which makes updating of bundles easier from the point of view that less other bundles are affected.
Of course, if you have a utility bundle and update it, you can also limit the effect of such an update by explicitly refreshing dependent bundles one by one, which means that instead of a "stop the world" effect you get more of a "rippling" effect, but that probably means writing your own management agent with such behaviour. Greetings, Marcel On 1 Dec 2010, at 4:13 , Wesley Silva wrote: > Thanks for the answers... > > On Tue, Nov 30, 2010 at 11:02 PM, Jeff McAffer <j...@eclipsesource.com> 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? >>> >>> -- >>> 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 > > > > -- > 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
