Marcel Offermans wrote:
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. Since it's not part of
the framework, I don't like including it in Felix by default. It just
increases the size of the core.
Part of the reason might be that it was thought of later and it wasn't
quite clear that it would eventually become regarded as an integral
part...however, that is just a guess on my part.
So in my opinion we should not include it by default.
Well, I could go either way. I just deployed a version of framework/main
that include it (along with a concurrency fix). I am more than willing
to put this up to a majority vote if we don't feel that we have general
consensus...
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.
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 agree this is yet another approach. I don't know which is best...
-> richard
