Sam Pullara wrote:
On Apr 25, 2008, at 5:19 PM, Richard S. Hall wrote:
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 have no problem with them using OSGi and I think it has a lot of
value. It just doesn't seem like you need to make it built into Java
but rather another container specification.
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.
This seems like a good plan. We'd have no problem wrapping this up
quickly with this as the goal.
However, that isn't the way we have been going, nor has it ever been
as far as I am aware.
I agree. I've been trying to push us this way since the beginning.
Unfortunately, me: FAIL.
Join the club...
-> richard
Sam