cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: FYI: OSGi JSR
Date Tue, 28 Feb 2006 20:00:49 GMT
I think there are lots of politics involved. Peter Kriens, OSGi spec 
author, evangelist and old timer was rejected to become a member of 
JSR277, and is upset about it: 
http://www.aqute.biz/2006/02/osgi-and-jsr-277-bad-vibes.html, (he have 
written a number of times about it on his blog).

Interesting enough Richard Hall, Felix lead and OSGi member, is part of 
both JSRs.

All the issues with OSGi listed in the citation from JSR 277 are solved 
in OSGi R4.

IBM seem to make a huge investment in OSGi while Sun doesn't, so I 
wouldn't be surprised if this is part of there fighting as well.

Anyway, standardized Java modularization is needed now, so waiting to 
Java 7, seem less attractive.

/Daniel

Stefano Mazzocchi wrote:
> Daniel Fagerstrom wrote:
>> Apache and some other well known organizations have started an JSR 
>> for dynamic component framework in Java SE based on OSGi.
>>
>> http://www.osgi.org/blog/2006/02/jsr-291-dynamic-component-support-for.html 
>>
>> http://www.jcp.org/en/jsr/detail?id=291
>
> 4 months to get a JSR out of the door? whatever.
>
>
> This seems a rushed up battle against JSR 277, which states:
>
> The current version of the Open Services Gateway Initiative (OSGi) 
> specification defines a framework that enables the deployment of 
> service-oriented applications (called bundles). However, the framework 
> only supports package dependency based on the minimum version of a 
> specification, and there is no support for exact version or version 
> range. The framework also supports package dependency based on an 
> implementation, but there is no support for versioning. Moreover, the 
> framework must choose one bundle that will be the provider of the 
> exported package for all bundles which have dependencies on that 
> package, so it is impossible to support more than one version of 
> shared package at runtime. Besides, the selection of exported package 
> provider is anonymous, and there is no way to influence the selection. 
> Because the versioning semantics in the OSGi framework is simplistic, 
> it is not a sufficient solution to address the JAR referencing problem.
>
>
>
> While JSR 291 states:
>
> No current JSR (either complete or in process) defines a dynamic 
> component and lifecycle solution to run on top of the existing family 
> of Java SE platforms. However, JSR 232 does include this capability to 
> run on top of Java ME (CDC based platforms) along with a comprehensive 
> set of mobility services.
>
> JSR 277 has been filed to examine changes to the static module 
> definition to be used within the Java SE platform for Java 7 (Dolphin) 
> and beyond. JSR 277 is targeted for specification delivery in 2H/2007 
> with RI/TCK delivery as an integral part of Dolphin in 2008.
>
> This JSR aims to address the current needs for dynamic components 
> based on existing Java SE platforms. When Dolphin becomes available, 
> the specification lead of this JSR will either perform a maintenance 
> release of this JSR or raise a follow on JSR to add Dolphin to the 
> list of compatible supported platforms and to exploit Dolphin 
> technology for static modules, as appropriate.
>
>
>
>
>
> These two JSRs are heading on a massive collision course.
>



Mime
View raw message