Sam Pullara wrote:
On Apr 25, 2008, at 4:46 PM, Richard S. Hall wrote:
Sam Pullara wrote:
The vast majority of people that are going to use this system will
have never heard of OSGI nor care about any of their more subtle
features and just want an easy way to leverage the vast amount of
libraries available (virtually all of them are not OSGi modules
today but are jar files in maven repositories). We shouldn't be
specing out some sort of uber container but rather a simple way to
tie code to its dependencies.
If this is all that people wanted, then we could just define
repositories and associated metadata and forget about all runtime
modularity support, but I strongly disagree that this is all people
want or else there wouldn't be such an upsurge in OSGi interest and
adoption.
I guess that is what I am arguing for. I don't see the critical need,
outside the internals of application servers and a very few plugin
based tools, for runtime modularity support. And if OSGi can load a
JSR-277 module then I feel like the interoperability job is done.
I can understand your point of view, but I think you need to take a look
around and see what kind of systems out there are creating either their
own plugin mechanism or using an existing framework (like OSGi) to
create a plugin mechanism. This is a huge area. It is actually one of
the biggest impacts that Java made with its class loader approach, it
brought code loading to the masses.
I could give countless examples that fall outside the "few tools" above
(heck, today I just ran across a gaming platform using OSGi), but I
won't go into that.
I might wholeheartedly accept your view if the powers to be decided to
pare down 277 to be just a repository model for Java JAR files, because
that could potentially be fairly easy for us to specify and get working
as an OSGi module repository (which is currently lacking). I have said
before that it makes sense to have 294 give us needed VM support for
modules, 277 give us repository support for modules, and 291 give us
run-time support for modules.
However, that isn't the way we have been going, nor has it ever been as
far as I am aware.
-> richard
Sam
