You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Daniel Fagerstrom <da...@nada.kth.se> on 2006/02/27 22:51:40 UTC
FYI: OSGi JSR
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
/Daniel
Re: FYI: OSGi JSR
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Tuesday 28 February 2006 21:20, Stefano Mazzocchi wrote:
> These two JSRs are heading on a massive collision course.
Not if the people involved don't want that to happen. The most important
difference (as I see it) between the two is that JSR-291 is a fast track
add-on for those who want it "now" (debatable how long that is, as you
pointed out). And for people like me, who are not on an upgrade train to JDK5
yet(!), which has been out ~2years already, and unlikely to run JDK7 for the
next 4-5 years, I think JSR-291 is providing a reasonable middle-ground.
Should it be a JSR?? Why not? Most JSRs are formalizations of stuff that
already exist...
And IIRC, Stefano, you are in the camp "rather something that works today,
than the perfect system in a few years" ;o)
If JSR-277 will come up with something that surpasses every bit and corner of
the JSR-291, then GREAT!
Let me remind you of a "good enough" collection API way back in time, I think
it was simply called JCL. It was available in 1997 (perhaps earlier) and
solved me a great deal of work back then. When the official Collection API
came out, its purpose was ending... No shame in that. :o)
Cheers
Niclas
Re: FYI: OSGi JSR
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
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.
>
Re: FYI: OSGi JSR
Posted by Stefano Mazzocchi <st...@mit.edu>.
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.
--
Stefano Mazzocchi
Research Scientist Digital Libraries Research Group
Massachusetts Institute of Technology location: E25-131C
77 Massachusetts Ave telephone: +1 (617) 253-1096
Cambridge, MA 02139-4307 email: stefanom at mit . edu
-------------------------------------------------------------------