Updates on Interoperability
Richard S. Hall
heavy at UNGOVERNED.ORG
Fri Apr 25 17:30:14 PDT 2008
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
>>> 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
>> 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...
More information about the jsr277-eg-observer