Marcel Offermans <[EMAIL PROTECTED]> wrote on 2007-05-22 13:20:51: > On May 22, 2007, at 18:07 , Richard S. Hall wrote: > > > Since the overall response has been positive (even though I am > > mostly in the "excess cruft" camp with Eric), I have gone ahead and > > added it. > > I'm also in that camp, but I was at a conference (without internet) > today, so I missed out on the initial discussion. > > I'm wondering, if ServiceTracker was supposed to be part of the > framework, why didn't OSGi define it as such.
Well, we weren't that bright in Release 1 :-) We learned shortly after Release 1 that the Service API is too hard to use correctly and thus added ServiceTracker in R2. Had we been smart enough up front, there may have only ever been ServiceTracker. > Since it's not part of > the framework, I don't like including it in Felix by default. It is not part of the framework package, but it is a key class to use for services. Perhaps OSGi should consider moving it from Compendium to Core spec? > It just > increases the size of the core. 14KB won't break the bank. > > So in my opinion we should not include it by default. > > > Of course, BND could solve this by having people just pull ST into > > their bundle. But if everyone were to do this, then the savings we > > see by not having ST in the framework JAR would be quickly > > outweighed by the multiple copies of ST embedded into all of the > > bundles that use it. > > If people don't need the whole compendium, they are free to create a > meaningful subset of it and use that. That's the other option they have. Yes, but you raise the bar for people to use the framework correctly. > > If people are using another dependency manager (such as iPOJO) then > they don't need to use ST and you might actually want to discourage > people from using it at all by not providing it. I don't think that is a good idea. iPOJO, DS, etc. cannot be used for all service needs. ST is a fundamental tool that should always be provided. > > > -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] office: +1 386 848 1781 mobile: +1 386 848 3788
