You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jcp-open@apache.org by "Geir Magnusson Jr." <ge...@pobox.com> on 2007/01/21 22:00:05 UTC
JSR 291 - public review
I'm looking at the materials for the public draft of JSR-291 as I
need to vote on it tomorrow.
I'm actually considering voting "no", even though we're on the expert
group, simply because there is no spec there. It's just a document
that says "See OSGi R4". Really - 1 page. Go download it :
http://www.jcp.org/en/jsr/detail?id=291
Opinions? i've cc-ed niclas because he's listed as being on the EG,
and Richard as I believe he actually represents us.
geir
Re: JSR 291 - public review
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Geir Magnusson Jr. wrote:
>
> On Jan 21, 2007, at 6:14 PM, Richard S. Hall wrote:
>
>> Geir Magnusson Jr. wrote:
>>>
>>> The JSR says that the "specification will define a dynamic component
>>> framework including component lifecycle for existing Java SE
>>> platforms" and further the JSR states that
>>>
>>> "This specification will be a subset of JSR 232 including the
>>> modularity and lifecycle aspects of the OSGi R4 framework but
>>> excluding the service aspects of the framework, declarative service
>>> support, and the services defined by JSR 232.
>>> The specification lead will track revisions in the JSR 232 and OSGi
>>> specifications as they apply to this JSR, and will publish updates
>>> to this JSR as those specifications are updated."
>>>
>>> In your opinion, has the JSR done that?
>>
>> Not a simple answer. First, I believe it is a subset of JSR 232,
>> because that includes stuff related to the mobile phone world that is
>> not in 291. Second, it did try to leave out services and there was
>> discussion on the EG mailing list about what/how to leave things out,
>> but in the end it proved too difficult to leave the service layer
>> completely out, since the module and life cycle layers were partially
>> exposed in services, such as the PackageAdmin service. Most services
>> are not part of 291, for example the OSGi compendium services are not
>> included.
>
> where is that noted?
Hmm. I think it would be by virtue of the fact that they are not
referenced from the EDR, only the core R4.1 spec PDF is included in the
EDR zip...I really don't know, perhaps you should be emailing Glyn
Normington, since he is the spec lead.
>>> Another question - given that there's no content to the spec offered
>>> by the EG, what's the point? OSGi exists, and is a solid spec.
>>> What's the point of a JSR that says "look over there" without saying
>>> anything itself?
>>
>> Again, I think one of the goals here was to try to bring the
>> communities together so that OSGi would not necessarily exist
>> completely independent of the JCP in the future. This had already
>> been done for Java ME via 232, so this is would just make it official
>> for Java SE.
>
>
> I have to ask - how is OSGi not independent of the JCP now w/ 291?
> I'm not trying to be antagonistic - I'm just trying to figure out how
> anything is different. Yes, changes went into 4.1, but you're an OSGi
> guy to start with...
>
> let me ask this a different way - why could changes happen if the
> forum was the JCP mailing list rather than the OSGi mailing list?
Well, I think the issue was that JCP members were given the opportunity
to have some voice in how R4 should be turned into R4.1, rather than
only allowing OSGi members to have a voice. To be clear, though, the
OSGi Alliance did not have plans for R4.1 before JSR 291, R4.1 came
about as a direct response to the discussion of the 291 EG mailing list.
>> I agree that OSGi is a solid spec, but without trying to bridge the
>> gap between the JCP and the OSGi Alliance, then it is as if OSGi
>> technology doesn't even exist as far as the JCP is concerned, and
>> that benefits no one in my opinion.
>
>
> And it exists now because there's a pointer to it?
It exists because the JCP is the standard way to introduce new
technology into Java.
-> richard
Re: JSR 291 - public review
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Jan 21, 2007, at 6:14 PM, Richard S. Hall wrote:
> Geir Magnusson Jr. wrote:
>>
>> The JSR says that the "specification will define a dynamic
>> component framework including component lifecycle for existing
>> Java SE platforms" and further the JSR states that
>>
>> "This specification will be a subset of JSR 232 including the
>> modularity and lifecycle aspects of the OSGi R4 framework but
>> excluding the service aspects of the framework, declarative
>> service support, and the services defined by JSR 232.
>> The specification lead will track revisions in the JSR 232 and
>> OSGi specifications as they apply to this JSR, and will publish
>> updates to this JSR as those specifications are updated."
>>
>> In your opinion, has the JSR done that?
>
> Not a simple answer. First, I believe it is a subset of JSR 232,
> because that includes stuff related to the mobile phone world that
> is not in 291. Second, it did try to leave out services and there
> was discussion on the EG mailing list about what/how to leave
> things out, but in the end it proved too difficult to leave the
> service layer completely out, since the module and life cycle
> layers were partially exposed in services, such as the PackageAdmin
> service. Most services are not part of 291, for example the OSGi
> compendium services are not included.
where is that noted?
>
>> Another question - given that there's no content to the spec
>> offered by the EG, what's the point? OSGi exists, and is a solid
>> spec. What's the point of a JSR that says "look over there"
>> without saying anything itself?
>
> Again, I think one of the goals here was to try to bring the
> communities together so that OSGi would not necessarily exist
> completely independent of the JCP in the future. This had already
> been done for Java ME via 232, so this is would just make it
> official for Java SE.
I have to ask - how is OSGi not independent of the JCP now w/ 291?
I'm not trying to be antagonistic - I'm just trying to figure out how
anything is different. Yes, changes went into 4.1, but you're an
OSGi guy to start with...
let me ask this a different way - why could changes happen if the
forum was the JCP mailing list rather than the OSGi mailing list?
>
> However, I cannot claim to necessarily have all the answers, since
> I am just an EG member.
>
> I agree that OSGi is a solid spec, but without trying to bridge the
> gap between the JCP and the OSGi Alliance, then it is as if OSGi
> technology doesn't even exist as far as the JCP is concerned, and
> that benefits no one in my opinion.
And it exists now because there's a pointer to it?
Re: JSR 291 - public review
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Geir Magnusson Jr. wrote:
>> Actually, I represent myself, because I am not an Apache member.
>
> We don't require membership to represent the ASF in an EG, just
> someone with a clue.
I stand corrected, but still, I am a member of the EG due to my OSGi
involvement.
>> The goal of JSR 291 was to try to unite the JCP and OSGi communities
>> and to bring a dynamic component environment (via OSGi) to existing
>> Java platforms. The approach for doing this was to take the OSGi R4
>> spec as a starting point and to let the expert group give input into
>> any other missing pieces. It has done this.
>
>
> And where is evidence of that? As far as I can tell, the spec is a
> glorified URL for OSGi R4.1.
Well, there is the mailing list archive, which I think is public, since
the mailing list was public. There would be no OSGi R4.1 if it weren't
for JSR 291.
>>
>> The early draft release zip file contains a draft copy of the OSGi
>> R4.1 spec, which includes changes to meet requirements raised by the
>> expert group. Not all requirements were met, due to time constraints,
>> but I believe that all requirements were acknowledged and discussed
>> and considered for OSGi R5.
>>
>> So, in short, I believe the JSR has accomplished what it set out to do.
>
> The JSR says that the "specification will define a dynamic component
> framework including component lifecycle for existing Java SE
> platforms" and further the JSR states that
>
> "This specification will be a subset of JSR 232 including the
> modularity and lifecycle aspects of the OSGi R4 framework but
> excluding the service aspects of the framework, declarative service
> support, and the services defined by JSR 232.
> The specification lead will track revisions in the JSR 232 and OSGi
> specifications as they apply to this JSR, and will publish updates to
> this JSR as those specifications are updated."
>
> In your opinion, has the JSR done that?
Not a simple answer. First, I believe it is a subset of JSR 232, because
that includes stuff related to the mobile phone world that is not in
291. Second, it did try to leave out services and there was discussion
on the EG mailing list about what/how to leave things out, but in the
end it proved too difficult to leave the service layer completely out,
since the module and life cycle layers were partially exposed in
services, such as the PackageAdmin service. Most services are not part
of 291, for example the OSGi compendium services are not included.
> Another question - given that there's no content to the spec offered
> by the EG, what's the point? OSGi exists, and is a solid spec.
> What's the point of a JSR that says "look over there" without saying
> anything itself?
Again, I think one of the goals here was to try to bring the communities
together so that OSGi would not necessarily exist completely independent
of the JCP in the future. This had already been done for Java ME via
232, so this is would just make it official for Java SE.
However, I cannot claim to necessarily have all the answers, since I am
just an EG member.
I agree that OSGi is a solid spec, but without trying to bridge the gap
between the JCP and the OSGi Alliance, then it is as if OSGi technology
doesn't even exist as far as the JCP is concerned, and that benefits no
one in my opinion.
-> richard
Re: JSR 291 - public review
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Jan 21, 2007, at 5:07 PM, Richard S. Hall wrote:
> Geir Magnusson Jr. wrote:
>> I'm looking at the materials for the public draft of JSR-291 as I
>> need to vote on it tomorrow.
>>
>> I'm actually considering voting "no", even though we're on the
>> expert group, simply because there is no spec there. It's just a
>> document that says "See OSGi R4". Really - 1 page. Go download it :
>>
>> http://www.jcp.org/en/jsr/detail?id=291
>>
>> Opinions? i've cc-ed niclas because he's listed as being on the
>> EG, and Richard as I believe he actually represents us.
>
> Actually, I represent myself, because I am not an Apache member.
We don't require membership to represent the ASF in an EG, just
someone with a clue.
>
> The goal of JSR 291 was to try to unite the JCP and OSGi
> communities and to bring a dynamic component environment (via OSGi)
> to existing Java platforms. The approach for doing this was to take
> the OSGi R4 spec as a starting point and to let the expert group
> give input into any other missing pieces. It has done this.
And where is evidence of that? As far as I can tell, the spec is a
glorified URL for OSGi R4.1.
>
> The early draft release zip file contains a draft copy of the OSGi
> R4.1 spec, which includes changes to meet requirements raised by
> the expert group. Not all requirements were met, due to time
> constraints, but I believe that all requirements were acknowledged
> and discussed and considered for OSGi R5.
>
> So, in short, I believe the JSR has accomplished what it set out to
> do.
The JSR says that the "specification will define a dynamic component
framework including component lifecycle for existing Java SE
platforms" and further the JSR states that
"This specification will be a subset of JSR 232 including the
modularity and lifecycle aspects of the OSGi R4 framework but
excluding the service aspects of the framework, declarative service
support, and the services defined by JSR 232.
The specification lead will track revisions in the JSR 232 and OSGi
specifications as they apply to this JSR, and will publish updates to
this JSR as those specifications are updated."
In your opinion, has the JSR done that?
Another question - given that there's no content to the spec offered
by the EG, what's the point? OSGi exists, and is a solid spec.
What's the point of a JSR that says "look over there" without saying
anything itself?
geir
>
> -> richard
Re: JSR 291 - public review
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Geir Magnusson Jr. wrote:
> I'm looking at the materials for the public draft of JSR-291 as I need
> to vote on it tomorrow.
>
> I'm actually considering voting "no", even though we're on the expert
> group, simply because there is no spec there. It's just a document
> that says "See OSGi R4". Really - 1 page. Go download it :
>
> http://www.jcp.org/en/jsr/detail?id=291
>
> Opinions? i've cc-ed niclas because he's listed as being on the EG,
> and Richard as I believe he actually represents us.
Actually, I represent myself, because I am not an Apache member.
The goal of JSR 291 was to try to unite the JCP and OSGi communities and
to bring a dynamic component environment (via OSGi) to existing Java
platforms. The approach for doing this was to take the OSGi R4 spec as a
starting point and to let the expert group give input into any other
missing pieces. It has done this.
The early draft release zip file contains a draft copy of the OSGi R4.1
spec, which includes changes to meet requirements raised by the expert
group. Not all requirements were met, due to time constraints, but I
believe that all requirements were acknowledged and discussed and
considered for OSGi R5.
So, in short, I believe the JSR has accomplished what it set out to do.
-> richard
Re: JSR 291 - public review
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Brett Porter wrote:
>
> On 22/01/2007, at 12:40 PM, Richard S. Hall wrote:
>
>> I can only speak from my experience, but if the ability to have
>> significant impact on the final result of a JSR is our yardstick,
>> then I think we will be voting "no" on most of them...at least from
>> my experience as a JCP EG member.
>
> I see your point here, but I disagree.
>
> I think we'd like to see all JSRs be more open and collaborative -
> nothing to argue there. I think it's great that there was some effort
> towards making this particular JSR more open.
I agree with you that I would like all JSRs to be more open, but that is
not an argument for singling out one as an example. Has any JSR ever
even let the public listen to the EG discussion?
> However, in the case of this JSR, these concerns were specifically
> raised in the ASF's yes vote and the no vote of other EC members to
> negate the impression that this was just "rubberstamping". My
> reasoning was that, from looking at the mail archives, what was done
> here was something that could have been achieved without the JSR. And
> that's fine - the OSGi spec can stand on it's own two feet.
>
> Either way, if yourself and the other EG members here feel that having
> a JSR was particularly beneficial and it couldn't have happened
> otherwise, then I'm not going to object. I just didn't get that
> impression from the mailing lists.
I am not saying that it couldn't have happened otherwise, I am saying it
wouldn't have happened otherwise. Most likely, OSGi would not have
released an updated R4.1 spec, it would have just waited for R5 some
time into the future. Of course, I don't claim to know the overall
release strategy of the OSGi Alliance.
> One other question I had that hasn't been discussed is the RI and TCK
> - we earlier encouraged these to be implemented through existing open
> source projects such as Felix or Equinox. Was there any movement
> towards this?
There has been moving in making the TCK open to open source communities.
I have sent Geir the license that Apache has to execute to get its
members access to the OSGi TCK, I am just waiting for advice on what to
do with it.
-> richard
Re: JSR 291 - public review
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Jan 22, 2007, at 7:16 PM, Roy T. Fielding wrote:
> On Jan 22, 2007, at 5:35 AM, Geir Magnusson Jr. wrote:
>>> 2) The Specification, RI, and TCK licenses are provided to the EC
>>> prior to the vote;
>>
>> We're not at that stage. This is just the public draft, but I
>> expect that will happen at the end of the process.
>>
>>>
>>> 3) The Specification and TCK licenses allow an open source
>>> implementation;
>>>
>>> 4) The above licenses are provided at no cost to nonprofit
>>> organizations like the ASF; and
>>
>> Both of these are required by the JCP, but I don't see how this is
>> going to work out yet. The license of the included OSGi spec is
>> for feedback and distribution only. I assume that you aren't
>> being licensed to implement the spec, even for internal
>> evaluation. That's unusual for even a JCP spec. Granted, this is
>> consistent with the license you agree to to review this spec which
>> doesn't mention implementation either.
>
> Actually, I think this is because of Sun legal's boilerplate license
> for the public review. The PMO required Day to do the same for JSR
> 170
> during the JCR review period, and then replaced the review license
> with
> the real license for the final review. In other words, I think this
> is a non-issue for now.
>
> I think we should vote Yes with a comment to the effect that all of
> this must be cleared up in the final submission. There should be a
> statement by the Spec Lead that indicates they have been licensed
> all of the intellectual property necessary from the OSGi Alliance
> members and that said IP is included in the Specification License.
>
> If that statement is given, then it is worthwhile having the JSR
> even if it merely rubberstamps OSGi work. Think of it as a shared
> legal agreement, rather than a new technology.
This is where I was going before my wife called me down for
dinner :) I'll finish the email now and send for review here.
geir
>
> ....Roy
Re: JSR 291 - public review
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Jan 22, 2007, at 5:35 AM, Geir Magnusson Jr. wrote:
>> 2) The Specification, RI, and TCK licenses are provided to the EC
>> prior to the vote;
>
> We're not at that stage. This is just the public draft, but I
> expect that will happen at the end of the process.
>
>>
>> 3) The Specification and TCK licenses allow an open source
>> implementation;
>>
>> 4) The above licenses are provided at no cost to nonprofit
>> organizations like the ASF; and
>
> Both of these are required by the JCP, but I don't see how this is
> going to work out yet. The license of the included OSGi spec is
> for feedback and distribution only. I assume that you aren't being
> licensed to implement the spec, even for internal evaluation.
> That's unusual for even a JCP spec. Granted, this is consistent
> with the license you agree to to review this spec which doesn't
> mention implementation either.
Actually, I think this is because of Sun legal's boilerplate license
for the public review. The PMO required Day to do the same for JSR 170
during the JCR review period, and then replaced the review license with
the real license for the final review. In other words, I think this
is a non-issue for now.
I think we should vote Yes with a comment to the effect that all of
this must be cleared up in the final submission. There should be a
statement by the Spec Lead that indicates they have been licensed
all of the intellectual property necessary from the OSGi Alliance
members and that said IP is included in the Specification License.
If that statement is given, then it is worthwhile having the JSR
even if it merely rubberstamps OSGi work. Think of it as a shared
legal agreement, rather than a new technology.
....Roy
Re: JSR 291 - public review
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Jan 22, 2007, at 3:27 AM, Roy T. Fielding wrote:
> On Jan 22, 2007, at 12:11 AM, Niclas Hedhman wrote:
>> Well, I hope you are aware of that a JSR is not required to provide
>> the RI and TCK "for free". The RI and TCK is available for licensing.
>
> Apache should vote "No" unless *all* of the following are true:
>
> 1) The specification is completely provided by the JSR publications
> (i.e., we don't need to jump through some other license hoops
> in order to read it);
The OSGi spec is included in the package, but under a different license.
>
> 2) The Specification, RI, and TCK licenses are provided to the EC
> prior to the vote;
We're not at that stage. This is just the public draft, but I expect
that will happen at the end of the process.
>
> 3) The Specification and TCK licenses allow an open source
> implementation;
>
> 4) The above licenses are provided at no cost to nonprofit
> organizations like the ASF; and
Both of these are required by the JCP, but I don't see how this is
going to work out yet. The license of the included OSGi spec is for
feedback and distribution only. I assume that you aren't being
licensed to implement the spec, even for internal evaluation. That's
unusual for even a JCP spec. Granted, this is consistent with the
license you agree to to review this spec which doesn't mention
implementation either.
Glyn?
>
> 5) The technology defines something useful for Java.
Yes, that's clear here. OSGi is good stuff.
>
>> Nothing different from other JSRs.
>
> Every JSR Spec Lead has the choice of a wide range of options to make
> it easier (or harder) for independent implementations, and that choice
> has widened over time. They are all different.
>
> I don't think it matters if OSGi gets a rubber stamp. What matters is
> that the result is specified accurately, readably, and in a form that
> we can implement.
There's a disconnect in IP flows - and I'm sure Glyn can comment.
The JSPA requires that patents reading on specific contributions to
the spec that are owned by the contributor are licensed to users and
distributors of compatible implementations in a RAND and royalty-free
basis. How will JSR291 bridge the gap, given that the contributors
to the OSGi spec aren't bound by the JSPA?
geir
Re: Any Final Thoughts? (Was Re: JSR 291 - public review)
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Jan 22, 2007, at 8:55 PM, Craig L Russell wrote:
>
> On Jan 22, 2007, at 5:36 PM, Geir Magnusson Jr. wrote:
>
>> So how do we vote? (answer below)
>>
>> Roy's criterion :
>>
>> On Jan 22, 2007, at 3:27 AM, Roy T. Fielding wrote:
>>
>>> Apache should vote "No" unless *all* of the following are true:
>>>
>>> 1) The specification is completely provided by the JSR
>>> publications
>>> (i.e., we don't need to jump through some other license hoops
>>> in order to read it);
>>
>> This appears to be met at this point.
>>
>>>
>>> 2) The Specification, RI, and TCK licenses are provided to the EC
>>> prior to the vote;
>>
>> I don't believe that licenses are applicable at this point.
>
> I don't agree, but we can clarify our position in the comments that
> accompany the vote.
The JSPA says that EGs are encouraged, not required.
>>
>>>
>>> 3) The Specification and TCK licenses allow an open source
>>> implementation;
>>
>> The TCK isn't germane at this point, but the spec license is, and
>> previous post had no problem. IIRC, the OSGi spec license is
>> sane, as is the OSGi TCK license.
>
> I agree. The OSGi license under which IBM says they intend to
> license 291 is ok.
>>
>>>
>>> 4) The above licenses are provided at no cost to nonprofit
>>> organizations like the ASF; and
>>
>> That's required by the JSPA.
>>
>>>
>>> 5) The technology defines something useful for Java.
>>
>> This is a judgement call, and we tend not to vote EC votes based
>> on that (or J2EE and the calendar API would have been toast long
>> ago ;).
>
> On the other hand, there is evidence of the value of this technology.
Agreed. But again, I want to be careful on how we consider this aspect.
>>
>>>
>>> I don't think it matters if OSGi gets a rubber stamp. What
>>> matters is
>>> that the result is specified accurately, readably, and in a form
>>> that
>>> we can implement.
>>
>> So my tally of people's eventual positions :
>>
>> +1 : Roy, Richard, Brett (hope I got that right), Niclas, David
>>
>> Not sure : Bruce
>>
>> License concerns : Craig
>>
>> I believe that Craig's concerns about licensing should be
>> mentioned in the voting statement.
>
> In short, my concern is that the intent to license the
> specification according to the terms of the OSGi license should be
> explicit in the release materials.
>
> And the intent to release the RI as the Equinox open source project
> is certainly relevant for this phase of the project.
Yep
>>
>> I went and looked back at our statement with our original approval
>> vote :
>>
>> "As we are a supporter of this JSR, and a proposed member of the
>> Expert Group, we would like to see this JSR begin. Apache has an
>> OSGi implementation project (http://incubator.apache.org/felix/),
>> and therefore has an interest in how the community standardizes
>> this technology in the Java ecosystem.
>>
>> That said, we do have concerns. We recognize that the objections
>> of other EC members about "rubberstamping" should not be
>> dismissed. However, we believe that this is a judgment that can
>> only be made later, and we welcome the opportunity to bridge two
>> technical communities and try to remove the obvious tension
>> between JSR-277 and OSGi.
>>
>> We emphasize our interest in seeing collaborative community
>> engagement in the expert group, and expect that as with any other
>> JSR, the proposed timeline will shift to accommodate the needs of
>> EG as it does it's work.
>>
>> Finally, we congratulate the spec lead on opening the expert group
>> mail list to read-only access to any interested party, and expect
>> that there will be no requirements for such access other than an
>> expression of interest. Further, in the interest of widespread
>> adoption, we again urge the spec lead to create the RI and TCK as
>> open source software, either through a new effort, or via one of
>> the existing open source communities currently engaged in OSGi
>> implementation."
>>
>> So the issues :
>>
>> 1) bridge the 277 and OSGi communities - there's some claim this
>> happened, but I'm not too convinced
>>
>> 2) "rubberstamp" - it's been argued by Richard and others that the
>> EG influenced the spec to create a v4.1, so it's not a total
>> rubberstamp. I'm not sure why this input couldn't have been done
>> in OSGi, but whatever. Also, there doesn't seem to be a good
>> argument why a rubberstamp is bad in itself.
>>
>> 3) Clearly the timeline shifted. IIRC, the original timeline was
>> really silly, calling for final approval by July 2006. It's good
>> to see that schedule isn't being adhered to.
>>
>> 4) The mail list was open, although there seem to be complains on
>> where some of the work was done.
>>
>> So all in all, not too bad, based on our original input.
>>
>> So unless someone can find a really compelling reason not to,
>> we'll vote yes with a statement listing our concerns and
>> requirements for the final ballot.
>
>> I'd like to list :
>>
>> 1) Require a clear statement that the necessary IP from all OSGi
>> members is licensed on a RAND and royalty-free basis to any
>> compatible independent implementation. This seems to be the
>> biggest problem.
>>
>> 2) Ask that they help set a precedent through the submission of a
>> TCK license that will be offered to any implementor. The spec
>> lead is of course able to offer any other license they choose as
>> an alternative. This is something we need to move to do for all
>> specs going forward. The lack of "ex-ante" disclosure on this is
>> a serious problem in the JCP.
>
> As is the lack of ex-ante disclosure of specification licensing
> terms. To my great surprise, spec license terms vary significantly
> for non-Sun-led JSRs.
I thought the spec license has specific requirements - but this isn't
a spec yet.
The sanest license I've seen so far is from BEA for a TCK we licensed
from them. Simple, clean, to the point. A real model for everyone
else.
>>
>> 3) Encourage them to choose an open source implementation as the RI
>>
>> 4) Encourage them to deliver the TCK as open source software.
>>
>> any more comments, additions, thoughts, or protest? Speak fast -
>> I need to do this tonight.
>
> Looks good.
Thanks
geir
>
> Craig
>>
>> geir
>>
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
Re: Any Final Thoughts? (Was Re: JSR 291 - public review)
Posted by Craig L Russell <Cr...@Sun.COM>.
On Jan 22, 2007, at 5:36 PM, Geir Magnusson Jr. wrote:
> So how do we vote? (answer below)
>
> Roy's criterion :
>
> On Jan 22, 2007, at 3:27 AM, Roy T. Fielding wrote:
>
>> Apache should vote "No" unless *all* of the following are true:
>>
>> 1) The specification is completely provided by the JSR publications
>> (i.e., we don't need to jump through some other license hoops
>> in order to read it);
>
> This appears to be met at this point.
>
>>
>> 2) The Specification, RI, and TCK licenses are provided to the EC
>> prior to the vote;
>
> I don't believe that licenses are applicable at this point.
I don't agree, but we can clarify our position in the comments that
accompany the vote.
>
>>
>> 3) The Specification and TCK licenses allow an open source
>> implementation;
>
> The TCK isn't germane at this point, but the spec license is, and
> previous post had no problem. IIRC, the OSGi spec license is sane,
> as is the OSGi TCK license.
I agree. The OSGi license under which IBM says they intend to license
291 is ok.
>
>>
>> 4) The above licenses are provided at no cost to nonprofit
>> organizations like the ASF; and
>
> That's required by the JSPA.
>
>>
>> 5) The technology defines something useful for Java.
>
> This is a judgement call, and we tend not to vote EC votes based on
> that (or J2EE and the calendar API would have been toast long ago ;).
On the other hand, there is evidence of the value of this technology.
>
>>
>> I don't think it matters if OSGi gets a rubber stamp. What
>> matters is
>> that the result is specified accurately, readably, and in a form that
>> we can implement.
>
> So my tally of people's eventual positions :
>
> +1 : Roy, Richard, Brett (hope I got that right), Niclas, David
>
> Not sure : Bruce
>
> License concerns : Craig
>
> I believe that Craig's concerns about licensing should be mentioned
> in the voting statement.
In short, my concern is that the intent to license the specification
according to the terms of the OSGi license should be explicit in the
release materials.
And the intent to release the RI as the Equinox open source project
is certainly relevant for this phase of the project.
>
> I went and looked back at our statement with our original approval
> vote :
>
> "As we are a supporter of this JSR, and a proposed member of the
> Expert Group, we would like to see this JSR begin. Apache has an
> OSGi implementation project (http://incubator.apache.org/felix/),
> and therefore has an interest in how the community standardizes
> this technology in the Java ecosystem.
>
> That said, we do have concerns. We recognize that the objections
> of other EC members about "rubberstamping" should not be
> dismissed. However, we believe that this is a judgment that can
> only be made later, and we welcome the opportunity to bridge two
> technical communities and try to remove the obvious tension between
> JSR-277 and OSGi.
>
> We emphasize our interest in seeing collaborative community
> engagement in the expert group, and expect that as with any other
> JSR, the proposed timeline will shift to accommodate the needs of
> EG as it does it's work.
>
> Finally, we congratulate the spec lead on opening the expert group
> mail list to read-only access to any interested party, and expect
> that there will be no requirements for such access other than an
> expression of interest. Further, in the interest of widespread
> adoption, we again urge the spec lead to create the RI and TCK as
> open source software, either through a new effort, or via one of
> the existing open source communities currently engaged in OSGi
> implementation."
>
> So the issues :
>
> 1) bridge the 277 and OSGi communities - there's some claim this
> happened, but I'm not too convinced
>
> 2) "rubberstamp" - it's been argued by Richard and others that the
> EG influenced the spec to create a v4.1, so it's not a total
> rubberstamp. I'm not sure why this input couldn't have been done
> in OSGi, but whatever. Also, there doesn't seem to be a good
> argument why a rubberstamp is bad in itself.
>
> 3) Clearly the timeline shifted. IIRC, the original timeline was
> really silly, calling for final approval by July 2006. It's good
> to see that schedule isn't being adhered to.
>
> 4) The mail list was open, although there seem to be complains on
> where some of the work was done.
>
> So all in all, not too bad, based on our original input.
>
> So unless someone can find a really compelling reason not to, we'll
> vote yes with a statement listing our concerns and requirements for
> the final ballot.
> I'd like to list :
>
> 1) Require a clear statement that the necessary IP from all OSGi
> members is licensed on a RAND and royalty-free basis to any
> compatible independent implementation. This seems to be the
> biggest problem.
>
> 2) Ask that they help set a precedent through the submission of a
> TCK license that will be offered to any implementor. The spec lead
> is of course able to offer any other license they choose as an
> alternative. This is something we need to move to do for all specs
> going forward. The lack of "ex-ante" disclosure on this is a
> serious problem in the JCP.
As is the lack of ex-ante disclosure of specification licensing
terms. To my great surprise, spec license terms vary significantly
for non-Sun-led JSRs.
>
> 3) Encourage them to choose an open source implementation as the RI
>
> 4) Encourage them to deliver the TCK as open source software.
>
> any more comments, additions, thoughts, or protest? Speak fast - I
> need to do this tonight.
Looks good.
Craig
>
> geir
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: Any Final Thoughts? (Was Re: JSR 291 - public review)
Posted by Brett Porter <br...@apache.org>.
On 23/01/2007, at 12:36 PM, Geir Magnusson Jr. wrote:
> +1 : Roy, Richard, Brett (hope I got that right), Niclas, David
Yep, for what it's worth, I'm in favour. Thanks all for answering my
queries.
Your comments for the ballot sound fine.
- Brett
Any Final Thoughts? (Was Re: JSR 291 - public review)
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
So how do we vote? (answer below)
Roy's criterion :
On Jan 22, 2007, at 3:27 AM, Roy T. Fielding wrote:
> Apache should vote "No" unless *all* of the following are true:
>
> 1) The specification is completely provided by the JSR publications
> (i.e., we don't need to jump through some other license hoops
> in order to read it);
This appears to be met at this point.
>
> 2) The Specification, RI, and TCK licenses are provided to the EC
> prior to the vote;
I don't believe that licenses are applicable at this point.
>
> 3) The Specification and TCK licenses allow an open source
> implementation;
The TCK isn't germane at this point, but the spec license is, and
previous post had no problem. IIRC, the OSGi spec license is sane,
as is the OSGi TCK license.
>
> 4) The above licenses are provided at no cost to nonprofit
> organizations like the ASF; and
That's required by the JSPA.
>
> 5) The technology defines something useful for Java.
This is a judgement call, and we tend not to vote EC votes based on
that (or J2EE and the calendar API would have been toast long ago ;).
>
> I don't think it matters if OSGi gets a rubber stamp. What matters is
> that the result is specified accurately, readably, and in a form that
> we can implement.
So my tally of people's eventual positions :
+1 : Roy, Richard, Brett (hope I got that right), Niclas, David
Not sure : Bruce
License concerns : Craig
I believe that Craig's concerns about licensing should be mentioned
in the voting statement.
I went and looked back at our statement with our original approval
vote :
"As we are a supporter of this JSR, and a proposed member of the
Expert Group, we would like to see this JSR begin. Apache has an
OSGi implementation project (http://incubator.apache.org/felix/), and
therefore has an interest in how the community standardizes this
technology in the Java ecosystem.
That said, we do have concerns. We recognize that the objections of
other EC members about "rubberstamping" should not be dismissed.
However, we believe that this is a judgment that can only be made
later, and we welcome the opportunity to bridge two technical
communities and try to remove the obvious tension between JSR-277 and
OSGi.
We emphasize our interest in seeing collaborative community
engagement in the expert group, and expect that as with any other
JSR, the proposed timeline will shift to accommodate the needs of EG
as it does it's work.
Finally, we congratulate the spec lead on opening the expert group
mail list to read-only access to any interested party, and expect
that there will be no requirements for such access other than an
expression of interest. Further, in the interest of widespread
adoption, we again urge the spec lead to create the RI and TCK as
open source software, either through a new effort, or via one of the
existing open source communities currently engaged in OSGi
implementation."
So the issues :
1) bridge the 277 and OSGi communities - there's some claim this
happened, but I'm not too convinced
2) "rubberstamp" - it's been argued by Richard and others that the EG
influenced the spec to create a v4.1, so it's not a total
rubberstamp. I'm not sure why this input couldn't have been done in
OSGi, but whatever. Also, there doesn't seem to be a good argument
why a rubberstamp is bad in itself.
3) Clearly the timeline shifted. IIRC, the original timeline was
really silly, calling for final approval by July 2006. It's good to
see that schedule isn't being adhered to.
4) The mail list was open, although there seem to be complains on
where some of the work was done.
So all in all, not too bad, based on our original input.
So unless someone can find a really compelling reason not to, we'll
vote yes with a statement listing our concerns and requirements for
the final ballot. I'd like to list :
1) Require a clear statement that the necessary IP from all OSGi
members is licensed on a RAND and royalty-free basis to any
compatible independent implementation. This seems to be the biggest
problem.
2) Ask that they help set a precedent through the submission of a TCK
license that will be offered to any implementor. The spec lead is of
course able to offer any other license they choose as an
alternative. This is something we need to move to do for all specs
going forward. The lack of "ex-ante" disclosure on this is a serious
problem in the JCP.
3) Encourage them to choose an open source implementation as the RI
4) Encourage them to deliver the TCK as open source software.
any more comments, additions, thoughts, or protest? Speak fast - I
need to do this tonight.
geir
Re: JSR 291 - public review
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
But the OSGi Alliance isn't party to this. It's up to the spec lead
to satisfy the requirements of the JCP
geir
On Jan 22, 2007, at 10:25 AM, Alex Karasulu wrote:
> David Nuescheler wrote:
>> I second Roy's statement completely and also agree with Niclas that
>> this may be good timing to lean on the OSGi Alliance to open up a
>> little more and cover the requirements of the ASF as stated by Roy.
>
> Coming in late here due to email issues. I also concur with Roy's
> statements 100% on every item and agree to lean on the OSGi Alliance.
>
> Regards,
> Alex
> <akarasulu.vcf>
Re: JSR 291 - public review
Posted by Alex Karasulu <ak...@apache.org>.
David Nuescheler wrote:
> I second Roy's statement completely and also agree with Niclas that
> this may be good timing to lean on the OSGi Alliance to open up a
> little more and cover the requirements of the ASF as stated by Roy.
Coming in late here due to email issues. I also concur with Roy's
statements 100% on every item and agree to lean on the OSGi Alliance.
Regards,
Alex
Re: JSR 291 - public review
Posted by David Nuescheler <da...@gmail.com>.
I second Roy's statement completely and also agree with Niclas that
this may be good timing to lean on the OSGi Alliance to open up a
little more and cover the requirements of the ASF as stated by Roy.
Maybe this would be worth a comment in the Public Review Ballot?
(or a even condition for Final Approval Ballot?)
regards,
david
Re: JSR 291 - public review
Posted by Glyn Normington <gl...@uk.ibm.com>.
Just catching up....
"Geir Magnusson Jr." <ge...@pobox.com> wrote on 21/01/2007 21:00:05:
> I'm looking at the materials for the public draft of JSR-291 as I
> need to vote on it tomorrow.
>
> I'm actually considering voting "no", even though we're on the expert
> group, simply because there is no spec there. It's just a document
> that says "See OSGi R4". Really - 1 page. Go download it :
>
> http://www.jcp.org/en/jsr/detail?id=291
> ...
I think Geir only saw the covering letter! The PR spec. package zip file
contains *three* documents:
1. covering letter,
2. license for the spec. package,
3. 286 page draft specification.
"Roy T. Fielding" <ro...@gmail.com> wrote on 22/01/2007 08:27:31:
> On Jan 22, 2007, at 12:11 AM, Niclas Hedhman wrote:
> > Well, I hope you are aware of that a JSR is not required to provide
> > the RI and TCK "for free". The RI and TCK is available for licensing.
>
> Apache should vote "No" unless *all* of the following are true:
>
> 1) The specification is completely provided by the JSR publications
> (i.e., we don't need to jump through some other license hoops
> in order to read it);
The JSR 291 PR spec. package contains the draft specification and the
necessary spec. license information.
>
> 2) The Specification, RI, and TCK licenses are provided to the EC
> prior to the vote;
For Public Review, JCP 2.6 requires only the specification to be provided
to the EC prior to the Public Draft Specification Approval Ballot.
Draft terms for the RI and TCK were included in the JSR submission. Final
RI and TCK terms do not need to be provided until the Final Approval
Ballot.
>
> 3) The Specification and TCK licenses allow an open source
> implementation;
Of course this is allowed and I expect at least the current three OSGi open
source projects (Eclipse Equinox, Apache Felix, Knopflerfish) to implement
the specification.
>
> 4) The above licenses are provided at no cost to nonprofit
> organizations like the ASF; and
This is the case by virtue of JSR 291 being covered by JCP 2.6. The JCP's
spec. lead guide says:
"JSRs under JCP 2.6 or later must also license the RI and TCK separately
and provide no cost access of TCKs to qualified individuals, educational
and not for profit organizations."
>
> 5) The technology defines something useful for Java.
I don't think anyone seriously doubts this, do they.
Glyn
Re: JSR 291 - public review
Posted by "Roy T. Fielding" <ro...@gmail.com>.
On Jan 22, 2007, at 12:11 AM, Niclas Hedhman wrote:
> Well, I hope you are aware of that a JSR is not required to provide
> the RI and TCK "for free". The RI and TCK is available for licensing.
Apache should vote "No" unless *all* of the following are true:
1) The specification is completely provided by the JSR publications
(i.e., we don't need to jump through some other license hoops
in order to read it);
2) The Specification, RI, and TCK licenses are provided to the EC
prior to the vote;
3) The Specification and TCK licenses allow an open source
implementation;
4) The above licenses are provided at no cost to nonprofit
organizations like the ASF; and
5) The technology defines something useful for Java.
> Nothing different from other JSRs.
Every JSR Spec Lead has the choice of a wide range of options to make
it easier (or harder) for independent implementations, and that choice
has widened over time. They are all different.
I don't think it matters if OSGi gets a rubber stamp. What matters is
that the result is specified accurately, readably, and in a form that
we can implement.
....Roy
Re: JSR 291 - public review
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Jan 22, 2007, at 3:11 AM, Niclas Hedhman wrote:
> On 1/22/07, David Nuescheler <da...@gmail.com> wrote:
>
>> Anyhow, I think "rubber stamping" in JCP is not that simple, since
>> there will be a need for
>> the Reference Implementation that passes the TCK later on in the
>> process and at least
>> the latter will certainly not be something that the JSR-291 EG can
>> just refer to with a link.
>
> Well, I hope you are aware of that a JSR is not required to provide
> the RI and TCK "for free". The RI and TCK is available for licensing.
> Nothing different from other JSRs.
TCKs are required to be free for qualified non-profits (like us),
individuals and academics.
>
> Hopefully, we can increase the pressure on the OSGi Alliance to make
> those available "for free" in due time. As my company has just become
> full members of the Alliance, I will try to push for such change from
> within.
IBM will have to guarantee this if it is a JCP spec.
geir
Re: JSR 291 - public review
Posted by Niclas Hedhman <ni...@hedhman.org>.
On 1/22/07, David Nuescheler <da...@gmail.com> wrote:
> Anyhow, I think "rubber stamping" in JCP is not that simple, since
> there will be a need for
> the Reference Implementation that passes the TCK later on in the
> process and at least
> the latter will certainly not be something that the JSR-291 EG can
> just refer to with a link.
Well, I hope you are aware of that a JSR is not required to provide
the RI and TCK "for free". The RI and TCK is available for licensing.
Nothing different from other JSRs.
Hopefully, we can increase the pressure on the OSGi Alliance to make
those available "for free" in due time. As my company has just become
full members of the Alliance, I will try to push for such change from
within.
Cheers
Niclas
Re: JSR 291 - public review
Posted by David Nuescheler <da...@gmail.com>.
Hi guys,
personally I have no issue with the fact that someone is "not" trying
to re-invent the wheel
in a JSR and is referring to an existing and working specification
that is actually implemented.
In this particular sense JSR-291 makes sense to me (especially over JSR-277).
Anyhow, I think "rubber stamping" in JCP is not that simple, since
there will be a need for
the Reference Implementation that passes the TCK later on in the
process and at least
the latter will certainly not be something that the JSR-291 EG can
just refer to with a link.
So generally, I am not opposed to "wrap" an existing standard into the formal
requirements (RI, TCK) of a JSR and in the special case of the
"Module-Business ;)"
I am actually in favor of it.
regards,
david
Re: JSR 291 - public review
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Niclas Hedhman wrote:
> On 1/22/07, Brett Porter <br...@apache.org> wrote:
>
>> I think we'd like to see all JSRs be more open and collaborative -
>> nothing to argue there. I think it's great that there was some effort
>> towards making this particular JSR more open.
>
> Ok. So ASF will vote NO on all future JSRs that are not totally
> transparent?
> I am fine with that, but please be consistent and not budge on
> principles, if that is what this is.
+1
>> raised in the ASF's yes vote and the no vote of other EC members to
>> negate the impression that this was just "rubberstamping". My
>> reasoning was that, from looking at the mail archives, what was done
>> here was something that could have been achieved without the JSR. And
>> that's fine - the OSGi spec can stand on it's own two feet.
> However, in the case of this JSR, these concerns were specifically
>
> Agree.
> But, this is not uncommon. The Spec Lead is responsible for the whole
> production process, and the Expert Group is an advisor board. The EG
> chats and the Spec Lead assimilate that and throws something over the
> fence for further discussions.
>
> The difference is that what is "thrown over the fence" is *very
> mature* and most EG members are probably quite content with what they
> see. Now, it seems, that have a mature starting point (something that
> works) is a handicap.
>
>> One other question I had that hasn't been discussed is the RI and TCK
>> - we earlier encouraged these to be implemented through existing open
>> source projects such as Felix or Equinox. Was there any movement
>> towards this?
>
> No, there wasn't. The Spec Lead has "promised" on behalf of the OSGi
> Alliance that TCK will be made available to Open Source organizations.
> ASF has access to the TCK via Richard Hall privately, and IIUIC that
> is how Felix achieves its compliance.
>
>
> Reasons for this JSR, IMHO, is not so much whether it is
> rubberstamping OSGi Alliance work or not, but downstream work that can
> happen straight in JCP, having a dependency on JSR-291. This allows
> non-OSGi Alliance members to actively work on extensions, and is a
> reducation in the significance of being an Alliance member.
>
> Everyone is talking about convergence towards the JCP, now when it
> happens it is a bad thing. People talk about more openess, 291 was
> more open than many, but that is a bad thing and *not enough*.
>
> FYI, RedHat voted NO to start the JSR. They have in its final stages
> requested (and granted) to enter the EG. There are probably many
> speculations around their decision to do so, but *I* think that JBoss
> has finally *discovered* OSGi and also want to have a dependency on a
> JCP accepted standard.
+1 to all of it...
I should just shut up and let Niclas speak for me... ;-)
-> richard
>
>
> Cheers
> Niclas
Re: JSR 291 - public review
Posted by Niclas Hedhman <ni...@hedhman.org>.
On 1/22/07, Brett Porter <br...@apache.org> wrote:
> I think we'd like to see all JSRs be more open and collaborative -
> nothing to argue there. I think it's great that there was some effort
> towards making this particular JSR more open.
Ok. So ASF will vote NO on all future JSRs that are not totally transparent?
I am fine with that, but please be consistent and not budge on
principles, if that is what this is.
> However, in the case of this JSR, these concerns were specifically
> raised in the ASF's yes vote and the no vote of other EC members to
> negate the impression that this was just "rubberstamping". My
> reasoning was that, from looking at the mail archives, what was done
> here was something that could have been achieved without the JSR. And
> that's fine - the OSGi spec can stand on it's own two feet.
Agree.
But, this is not uncommon. The Spec Lead is responsible for the whole
production process, and the Expert Group is an advisor board. The EG
chats and the Spec Lead assimilate that and throws something over the
fence for further discussions.
The difference is that what is "thrown over the fence" is *very
mature* and most EG members are probably quite content with what they
see. Now, it seems, that have a mature starting point (something that
works) is a handicap.
> One other question I had that hasn't been discussed is the RI and TCK
> - we earlier encouraged these to be implemented through existing open
> source projects such as Felix or Equinox. Was there any movement
> towards this?
No, there wasn't. The Spec Lead has "promised" on behalf of the OSGi
Alliance that TCK will be made available to Open Source organizations.
ASF has access to the TCK via Richard Hall privately, and IIUIC that
is how Felix achieves its compliance.
Reasons for this JSR, IMHO, is not so much whether it is
rubberstamping OSGi Alliance work or not, but downstream work that can
happen straight in JCP, having a dependency on JSR-291. This allows
non-OSGi Alliance members to actively work on extensions, and is a
reducation in the significance of being an Alliance member.
Everyone is talking about convergence towards the JCP, now when it
happens it is a bad thing. People talk about more openess, 291 was
more open than many, but that is a bad thing and *not enough*.
FYI, RedHat voted NO to start the JSR. They have in its final stages
requested (and granted) to enter the EG. There are probably many
speculations around their decision to do so, but *I* think that JBoss
has finally *discovered* OSGi and also want to have a dependency on a
JCP accepted standard.
Cheers
Niclas
Re: JSR 291 - public review
Posted by Brett Porter <br...@apache.org>.
On 22/01/2007, at 12:40 PM, Richard S. Hall wrote:
> I understand your point, but no EG members started any discussion...
Fair point :)
>
> I can only speak from my experience, but if the ability to have
> significant impact on the final result of a JSR is our yardstick,
> then I think we will be voting "no" on most of them...at least from
> my experience as a JCP EG member.
I see your point here, but I disagree.
I think we'd like to see all JSRs be more open and collaborative -
nothing to argue there. I think it's great that there was some effort
towards making this particular JSR more open.
However, in the case of this JSR, these concerns were specifically
raised in the ASF's yes vote and the no vote of other EC members to
negate the impression that this was just "rubberstamping". My
reasoning was that, from looking at the mail archives, what was done
here was something that could have been achieved without the JSR. And
that's fine - the OSGi spec can stand on it's own two feet.
Either way, if yourself and the other EG members here feel that
having a JSR was particularly beneficial and it couldn't have
happened otherwise, then I'm not going to object. I just didn't get
that impression from the mailing lists.
One other question I had that hasn't been discussed is the RI and TCK
- we earlier encouraged these to be implemented through existing open
source projects such as Felix or Equinox. Was there any movement
towards this?
- Brett
Re: JSR 291 - public review
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Brett Porter wrote:
> Frankly, I'm torn on this.
>
> The group did seem to attempt to address the concerns of the EC
> members by extending the timeline (though I'm not sure when or why
> this happened), and making an attempt to bridge the JCP and OSGi
> communities rather than just rubberstamping the existing spec, as
> Richard said. However, while I get the feeling that this was certainly
> intended, I don't think it was very successful.
>
> I'm concerned by a couple of things on the mailing list:
> - I couldn't find it anywhere public (can someone point that out to
> me?). I was only able to find out where it lived by logging in as a
> JCP member.
Anyone could ask the spec lead to be on the mailing list, I think the
JSR says this, but I am not sure. The public could not comment however,
just listen.
> - there was limited discussion on the actual changes made - the
> biggest discussion was really around the overlap of JSR 277 and JSR 291
> - it seemed a lot of the actual work happened on the OSGi bugzilla and
> lists that were closed to the JSR 291 EG members
You are on 277 too, aren't you? The work there certainly doesn't happen
on the mailing list either.
The discussion of how to address EG concerns was discussed internally in
the OSGi Alliance, but the results of those discussions were summarized
to the EG.
> - the last few months have basically been postings by the spec lead
> saying that CPEG (the OSGi EG) have either accepted or rejected an
> issue. There was an explanation, but there was no discussion after
> that, which I found surprising. That means that between the EDR (which
> did not include any of the EG's use cases) and the PR (which does),
> there was no discussion on list about the spec.
I understand your point, but no EG members started any discussion...
> Maybe I'm missing something, but I get the impression that whatever
> the intent, the members of the EG that are not already OSGi members
> had little impact on the spec. I think it sets a bad precedent and am
> inclined towards a no vote.
>
> However, I'd first like to hear from Niclas who was quite active on
> the lists, and from Alex Karasulu who I believe was our official rep
> on this (not listed in the actual file, just from memory).
I can only speak from my experience, but if the ability to have
significant impact on the final result of a JSR is our yardstick, then I
think we will be voting "no" on most of them...at least from my
experience as a JCP EG member.
-> richard
>
> Cheers,
> Brett
>
> On 22/01/2007, at 11:33 AM, Bruce Snyder wrote:
>
>> On 1/21/07, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>>> I'm looking at the materials for the public draft of JSR-291 as I
>>> need to vote on it tomorrow.
>>>
>>> I'm actually considering voting "no", even though we're on the expert
>>> group, simply because there is no spec there. It's just a document
>>> that says "See OSGi R4". Really - 1 page. Go download it :
>>>
>>> http://www.jcp.org/en/jsr/detail?id=291
>>>
>>> Opinions? i've cc-ed niclas because he's listed as being on the EG,
>>> and Richard as I believe he actually represents us.
>>
>> I'm not sure I'm in favor of it either, even though I'm on the EG. My
>> intention was never to just rubber stamp the OSGi spec, as I think
>> that the OSGi has no place in the JSE.
>>
>> Bruce
>> --perl -e 'print
>> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
>> );'
>>
>> Apache Geronimo - http://geronimo.apache.org/
>> Apache ActiveMQ - http://activemq.org/
>> Apache ServiceMix - http://servicemix.org/
>> Castor - http://castor.org/
Re: JSR 291 - public review
Posted by Brett Porter <br...@apache.org>.
Frankly, I'm torn on this.
The group did seem to attempt to address the concerns of the EC
members by extending the timeline (though I'm not sure when or why
this happened), and making an attempt to bridge the JCP and OSGi
communities rather than just rubberstamping the existing spec, as
Richard said. However, while I get the feeling that this was
certainly intended, I don't think it was very successful.
I'm concerned by a couple of things on the mailing list:
- I couldn't find it anywhere public (can someone point that out to
me?). I was only able to find out where it lived by logging in as a
JCP member.
- there was limited discussion on the actual changes made - the
biggest discussion was really around the overlap of JSR 277 and JSR 291
- it seemed a lot of the actual work happened on the OSGi bugzilla
and lists that were closed to the JSR 291 EG members
- the last few months have basically been postings by the spec lead
saying that CPEG (the OSGi EG) have either accepted or rejected an
issue. There was an explanation, but there was no discussion after
that, which I found surprising. That means that between the EDR
(which did not include any of the EG's use cases) and the PR (which
does), there was no discussion on list about the spec.
Maybe I'm missing something, but I get the impression that whatever
the intent, the members of the EG that are not already OSGi members
had little impact on the spec. I think it sets a bad precedent and am
inclined towards a no vote.
However, I'd first like to hear from Niclas who was quite active on
the lists, and from Alex Karasulu who I believe was our official rep
on this (not listed in the actual file, just from memory).
Cheers,
Brett
On 22/01/2007, at 11:33 AM, Bruce Snyder wrote:
> On 1/21/07, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>> I'm looking at the materials for the public draft of JSR-291 as I
>> need to vote on it tomorrow.
>>
>> I'm actually considering voting "no", even though we're on the expert
>> group, simply because there is no spec there. It's just a document
>> that says "See OSGi R4". Really - 1 page. Go download it :
>>
>> http://www.jcp.org/en/jsr/detail?id=291
>>
>> Opinions? i've cc-ed niclas because he's listed as being on the EG,
>> and Richard as I believe he actually represents us.
>
> I'm not sure I'm in favor of it either, even though I'm on the EG. My
> intention was never to just rubber stamp the OSGi spec, as I think
> that the OSGi has no place in the JSE.
>
> Bruce
> --
> perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!
> G;6%I;\"YC;VT*"
> );'
>
> Apache Geronimo - http://geronimo.apache.org/
> Apache ActiveMQ - http://activemq.org/
> Apache ServiceMix - http://servicemix.org/
> Castor - http://castor.org/
Re: JSR 291 - public review
Posted by Steve Loughran <st...@apache.org>.
Niclas Hedhman wrote:
> On 1/22/07, Bruce Snyder <br...@gmail.com> wrote:
>
>> I'm not sure I'm in favor of it either, even though I'm on the EG. My
>> intention was never to just rubber stamp the OSGi spec,
>
> Then your job is to speak up... ;o)
>
>> as I think
>> that the OSGi has no place in the JSE.
>
> What? I can only interpret this mean 2 things. Either;
>
> 1. You think OSGi should not be deployed on Java SE.
>
> 2. You think OSGi should not be shipped with the JDK.
I think JAX-WS should not have been shipped with the JDK along with
sun's toy http server. Compared to that, OSGi is noise. It does at least
make sense architecturally.
>
> I assume you mean the second one, as the first one is hilariously silly...
>
> Well, IMHO, the JDK is over bloated since long, and the main focus
> around release 1,2/1.3 should have been something like what we now see
> in the JSR-277, allowing for simple extensions of the runtime
> platform.
>
> Now, that said; Please take a look at the 300 or so JSRs so far, and
> see how many is or will be shipping in either the JDK or is part of
> the non-optional Java EE specification set.
Java EE is full of junk; backwards compat stuff that doesnt make sense,
architectural errors, etc. It needs to go more componentized too.
Its interesting to watch Sun's reaction to this one. I understand Hani's
-ve vote, but I think Sun just don't like OSGi as it represents a loss
of control to them. The JCP is meant to be docile input from the
community, like those warsaw pact meetings where the delegate from
hungary would thank the CCCP representative for providing support to
help deal with revisionist counter-revolutionary forces. Now we have
another major player -IBM- striking out on their own.
Regarding the TCK, I think projects should embrace public SCM
repositories and make the entire test suite visible as live code, not
something secret. There is only one normative "standard" that Gump
builds on a nightly basis, and its an OASIS/Grid Forum one, not a JCP
thing. Shame.
-steve
Re: JSR 291 - public review
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Bruce Snyder wrote:
> On 1/21/07, Niclas Hedhman <ni...@hedhman.org> wrote:
>> On 1/22/07, Bruce Snyder <br...@gmail.com> wrote:
>>
>> > I'm not sure I'm in favor of it either, even though I'm on the EG. My
>> > intention was never to just rubber stamp the OSGi spec,
>>
>> Then your job is to speak up... ;o)
>>
>> > as I think
>> > that the OSGi has no place in the JSE.
>>
>> What? I can only interpret this mean 2 things. Either;
>>
>> 1. You think OSGi should not be deployed on Java SE.
>>
>> 2. You think OSGi should not be shipped with the JDK.
>>
>> I assume you mean the second one, as the first one is hilariously
>> silly...
>
> Yes, number two is what I meant.
The goal of JSR 291 does NOT include being shipped with JDK, it targets
existing Java SE platforms and potentially alignment with whatever comes
out of 277, but from my understanding it will not ship with the JDK...no
matter how desparately Java needs its capabilities. :-)
-> richard
>> around release 1,2/1.3 should have been something like what we now see
>> in the JSR-277, allowing for simple extensions of the runtime
>> platform.
> Well, IMHO, the JDK is over bloated since long, and the main focus
>
> Agreed.
>
>> Now, that said; Please take a look at the 300 or so JSRs so far, and
>> see how many is or will be shipping in either the JDK or is part of
>> the non-optional Java EE specification set.
>
> Ugh.
>
> Bruce
Re: JSR 291 - public review
Posted by Bruce Snyder <br...@gmail.com>.
On 1/21/07, Niclas Hedhman <ni...@hedhman.org> wrote:
> On 1/22/07, Bruce Snyder <br...@gmail.com> wrote:
>
> > I'm not sure I'm in favor of it either, even though I'm on the EG. My
> > intention was never to just rubber stamp the OSGi spec,
>
> Then your job is to speak up... ;o)
>
> > as I think
> > that the OSGi has no place in the JSE.
>
> What? I can only interpret this mean 2 things. Either;
>
> 1. You think OSGi should not be deployed on Java SE.
>
> 2. You think OSGi should not be shipped with the JDK.
>
> I assume you mean the second one, as the first one is hilariously silly...
Yes, number two is what I meant.
> Well, IMHO, the JDK is over bloated since long, and the main focus
> around release 1,2/1.3 should have been something like what we now see
> in the JSR-277, allowing for simple extensions of the runtime
> platform.
Agreed.
> Now, that said; Please take a look at the 300 or so JSRs so far, and
> see how many is or will be shipping in either the JDK or is part of
> the non-optional Java EE specification set.
Ugh.
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
Apache Geronimo - http://geronimo.apache.org/
Apache ActiveMQ - http://activemq.org/
Apache ServiceMix - http://servicemix.org/
Castor - http://castor.org/
Re: JSR 291 - public review
Posted by Niclas Hedhman <ni...@hedhman.org>.
On 1/22/07, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>
> On Jan 21, 2007, at 9:57 PM, Niclas Hedhman wrote:
>
> > On 1/22/07, Bruce Snyder <br...@gmail.com> wrote:
> >
> >> I'm not sure I'm in favor of it either, even though I'm on the EG. My
> >> intention was never to just rubber stamp the OSGi spec,
> >
> > Then your job is to speak up... ;o)
> >
> >> as I think
> >> that the OSGi has no place in the JSE.
> >
> > What? I can only interpret this mean 2 things. Either;
> >
> > 1. You think OSGi should not be deployed on Java SE.
> >
> > 2. You think OSGi should not be shipped with the JDK.
> >
> > I assume you mean the second one, as the first one is hilariously
> > silly...
> >
> > Well, IMHO, the JDK is over bloated since long, and the main focus
> > around release 1,2/1.3 should have been something like what we now see
> > in the JSR-277, allowing for simple extensions of the runtime
> > platform.
> >
> > Now, that said; Please take a look at the 300 or so JSRs so far, and
> > see how many is or will be shipping in either the JDK or is part of
> > the non-optional Java EE specification set.
> >
>
> This is off topic. Not necessarily wrong, but off topic.
>
> can you give us your opinion on how the ASF should vote on this?
If that question is directed to me, let me remind you that I am not an
ASF member, and Alex is the ASF rep in this. I hope the question was
more directed to jcp-open@ in general... ;o)
Personally, I would be very delighted if ASF is supporting this JSR,
which seems more controversial at the political arena than the
technical one (which few disputes). After some brushes with politics
in OSS, I have decided to stay away if possible. I trust you guys to
make a balanced decision.
Cheers
Niclas
Re: JSR 291 - public review
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Jan 21, 2007, at 9:57 PM, Niclas Hedhman wrote:
> On 1/22/07, Bruce Snyder <br...@gmail.com> wrote:
>
>> I'm not sure I'm in favor of it either, even though I'm on the EG. My
>> intention was never to just rubber stamp the OSGi spec,
>
> Then your job is to speak up... ;o)
>
>> as I think
>> that the OSGi has no place in the JSE.
>
> What? I can only interpret this mean 2 things. Either;
>
> 1. You think OSGi should not be deployed on Java SE.
>
> 2. You think OSGi should not be shipped with the JDK.
>
> I assume you mean the second one, as the first one is hilariously
> silly...
>
> Well, IMHO, the JDK is over bloated since long, and the main focus
> around release 1,2/1.3 should have been something like what we now see
> in the JSR-277, allowing for simple extensions of the runtime
> platform.
>
> Now, that said; Please take a look at the 300 or so JSRs so far, and
> see how many is or will be shipping in either the JDK or is part of
> the non-optional Java EE specification set.
>
This is off topic. Not necessarily wrong, but off topic.
can you give us your opinion on how the ASF should vote on this?
geir
Re: JSR 291 - public review
Posted by Niclas Hedhman <ni...@hedhman.org>.
On 1/22/07, Bruce Snyder <br...@gmail.com> wrote:
> I'm not sure I'm in favor of it either, even though I'm on the EG. My
> intention was never to just rubber stamp the OSGi spec,
Then your job is to speak up... ;o)
> as I think
> that the OSGi has no place in the JSE.
What? I can only interpret this mean 2 things. Either;
1. You think OSGi should not be deployed on Java SE.
2. You think OSGi should not be shipped with the JDK.
I assume you mean the second one, as the first one is hilariously silly...
Well, IMHO, the JDK is over bloated since long, and the main focus
around release 1,2/1.3 should have been something like what we now see
in the JSR-277, allowing for simple extensions of the runtime
platform.
Now, that said; Please take a look at the 300 or so JSRs so far, and
see how many is or will be shipping in either the JDK or is part of
the non-optional Java EE specification set.
Cheers
Niclas
Re: JSR 291 - public review
Posted by Bruce Snyder <br...@gmail.com>.
On 1/21/07, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> I'm looking at the materials for the public draft of JSR-291 as I
> need to vote on it tomorrow.
>
> I'm actually considering voting "no", even though we're on the expert
> group, simply because there is no spec there. It's just a document
> that says "See OSGi R4". Really - 1 page. Go download it :
>
> http://www.jcp.org/en/jsr/detail?id=291
>
> Opinions? i've cc-ed niclas because he's listed as being on the EG,
> and Richard as I believe he actually represents us.
I'm not sure I'm in favor of it either, even though I'm on the EG. My
intention was never to just rubber stamp the OSGi spec, as I think
that the OSGi has no place in the JSE.
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
Apache Geronimo - http://geronimo.apache.org/
Apache ActiveMQ - http://activemq.org/
Apache ServiceMix - http://servicemix.org/
Castor - http://castor.org/