Another way would be to use a jar so that code can be easily shared but have each bundle embed its own copy of that class, so you don't add another dependency on the bundle and keep things more cohesive.
Anyway, if you write a bundle out of a utility classes, make sure the bundle doesn't import its exported packages. On Wed, Dec 1, 2010 at 03:13, Wesley Silva <wesle...@gmail.com> 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 > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
