[gentoo-java] Want to affect how JSRs are developed?

[gentoo-java] Want to affect how JSRs are developed?

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 154 bytes --]

http://today.java.net/pub/pq/155

Having them as open source would help Gentoo so please cast your vote.

Regards,
Petteri
--
Gentoo/Java lead.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-java] Want to affect how JSRs are developed?

[robert burrell donkin]

(in the interests of full disclosure on what is a delicate issue i am
an apache member but the opinions i express are purely personal)

On 4/20/07, Petteri Räty <betelgeuse@gentoo.org> wrote:
> http://today.java.net/pub/pq/155
>
> Having them as open source would help Gentoo so please cast your vote.

this is a very good time for the GNU/linux community to actively
influence the JCP and so the future of java. sun is very focussed ATM
on developing good relations with the GNU/linux community and seems to
be listening hard to their concerns.

it is clear that major changes are happening at the JCP

JEE6 has recently been withdrawn by sun. i do not know the reasons for
this. however, the public comments by the EC voters expressed concerns
about licensing and governance.

the governance issues raised by the apache open letter are still
outstanding and unresolved. the story of the first decade of the JCP
has very much been intertwined with the story of jakarta and the
relationship between apache and sun. it's unclear ATM whether this
relationship will survive.

(if the JCP survives the current crisis then) the second decade seems
likely to have a different theme. a good time for the GNU/linux
community to think about the process it wants since it may well have
the ability to shape it's evolution.

- robert
--
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] Want to affect how JSRs are developed?

[William L. Thomson Jr.]

[-- Attachment #1: Type: text/plain, Size: 1273 bytes --]

On Sun, 2007-04-22 at 18:48 +0100, robert burrell donkin wrote:
>
> the governance issues raised by the apache open letter are still
> outstanding and unresolved. the story of the first decade of the JCP
> has very much been intertwined with the story of jakarta and the
> relationship between apache and sun. it's unclear ATM whether this
> relationship will survive.

From what I have seen and heard that relationship ended some time ago. I
do not believe any Sun peeps are committing to apache/jakarta projects.
From poking around glassfish-servlet-api seems to be based on jakarta
tomcat sources, which is basically Tomcat 4.x(maybe 5.0.x, surely not
5.5.x).

Since Tomcat as of 4.x was the official reference implementation of
servlet 2.3/jsp 1.2 api's. But not clear if that's the case for 5.0 or
5.x 2.4/2.0, and surely not with 6.x 2.5/2.1.

Seems there were some differences there amongst developers, and it has
been pretty much completely severed. I also noticed in glassfish some
sun-commons stuff, so not sure if they are duplicating that as well.

No clue where all this is going, aside from having multiple
implementations for allot of things. But surely seems as if there has
been a fork.

-- 
William L. Thomson Jr.
Gentoo/Java

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-java] Want to affect how JSRs are developed?

[robert burrell donkin]

On 4/22/07, William L. Thomson Jr. <wltjr@gentoo.org> wrote:
> On Sun, 2007-04-22 at 18:48 +0100, robert burrell donkin wrote:
> >
> > the governance issues raised by the apache open letter are still
> > outstanding and unresolved. the story of the first decade of the JCP
> > has very much been intertwined with the story of jakarta and the
> > relationship between apache and sun. it's unclear ATM whether this
> > relationship will survive.
>
> From what I have seen and heard that relationship ended some time ago. I
> do not believe any Sun peeps are committing to apache/jakarta projects.

jakarta has been split into top level projects

there is plenty of activity elsewhere at apache involving committers
with links to sun. see for example
http://incubator.apache.org/projects/river.html,
http://db.apache.org/jdo/, http://shale.apache.org/ (i could do on but
won't). however, i'm not sure how many of those work on apache code as
part of their job.

> From poking around glassfish-servlet-api seems to be based on jakarta
> tomcat sources, which is basically Tomcat 4.x(maybe 5.0.x, surely not
> 5.5.x).

that doesn't surprise me

> Since Tomcat as of 4.x was the official reference implementation of
> servlet 2.3/jsp 1.2 api's. But not clear if that's the case for 5.0 or
> 5.x 2.4/2.0, and surely not with 6.x 2.5/2.1.

J2EE1.4 (2.4) RI contains tomcat but i don't think there's a separate
RI for the servlet container specification

> Seems there were some differences there amongst developers, and it has
> been pretty much completely severed.

most of the 3.x/4.x tomcat developers have moved onto new open source
projects. i don't know of any who are working on servlet containers
anymore outside apache.

> I also noticed in glassfish some
> sun-commons stuff, so not sure if they are duplicating that as well.

most likely that's just part of their effort to open sourcing most of
their code base

> No clue where all this is going, aside from having multiple
> implementations for allot of things. But surely seems as if there has
> been a fork.

the fork really happened back with the tomcat 3.0 donation. the apache
implementation has been independent since then.

- robert
-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] Want to affect how JSRs are developed?

[William L. Thomson Jr.]

[-- Attachment #1: Type: text/plain, Size: 2837 bytes --]

On Sun, 2007-04-22 at 21:30 +0100, robert burrell donkin wrote: 
> On 4/22/07, William L. Thomson Jr. <wltjr@gentoo.org> wrote:
> > 
> > From what I have seen and heard that relationship ended some time ago. I
> > do not believe any Sun peeps are committing to apache/jakarta projects.
> 
> jakarta has been split into top level projects

Not sure about that statement. Jakarta projects like tomcat have been
moved to top level apache projects now. Jakarta is like an incubator for
applications before they become top level/apache projects.

> there is plenty of activity elsewhere at apache involving committers
> with links to sun. see for example
> http://incubator.apache.org/projects/river.html,
> http://db.apache.org/jdo/, http://shale.apache.org/ (i could do on but
> won't). however, i'm not sure how many of those work on apache code as
> part of their job.

That was my point. To the best of my understanding very few if any Sun
employees contribute to Apache/Jakarta projects. Sun employees
contributing to the FOSS java world are doing so via java.net or what
ever that's called. Pretty sure it's not part of the JCP but might be.

> J2EE1.4 (2.4) RI contains tomcat but i don't think there's a separate
> RI for the servlet container specification

Ok, then Tomcat is the reference up to Servlet API 2.4/JSP API 2.0.
Still pretty sure that is not the case for Tomcat 6.x Servlet API
2.5/JSP API 2.1.

> > Seems there were some differences there amongst developers, and it has
> > been pretty much completely severed.
> 
> most of the 3.x/4.x tomcat developers have moved onto new open source
> projects. i don't know of any who are working on servlet containers
> anymore outside apache.

Like other containers? Resin, Jetty, etc?

> > I also noticed in glassfish some
> > sun-commons stuff, so not sure if they are duplicating that as well.
> 
> most likely that's just part of their effort to open sourcing most of
> their code base

No it seems to me to be a result of the fork. Now there will be apache
commons stuff and sun commons stuff.


> the fork really happened back with the tomcat 3.0 donation. the apache
> implementation has been independent since then.

No there has been another much more recent fork. Although I am not sure
how much is out in public space. Seems there is a current dispute over
licenses and etc wrt to Harmony
http://www.pcworld.com/article/id,130574/article.html

Just to show recent and current rifts. How deep this goes, hard to say,
but seems.

Seems this stuff started long ago though
http://www.internetnews.com/dev-news/article.php/10_998071

Bottom line I am seeing some duplicate code bases. Or places where there
is great potential for past code base fork to exist.


-- 
William L. Thomson Jr.
Gentoo/Java

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-java] Want to affect how JSRs are developed?

[robert burrell donkin]

On 4/24/07, William L. Thomson Jr. <wltjr@gentoo.org> wrote:
> On Sun, 2007-04-22 at 21:30 +0100, robert burrell donkin wrote:
> > On 4/22/07, William L. Thomson Jr. <wltjr@gentoo.org> wrote:
> > >
> > > From what I have seen and heard that relationship ended some time ago. I
> > > do not believe any Sun peeps are committing to apache/jakarta projects.
> >
> > jakarta has been split into top level projects
>
> Not sure about that statement. Jakarta projects like tomcat have been
> moved to top level apache projects now. Jakarta is like an incubator for
> applications before they become top level/apache projects.

this happens in the incubator project now

> > there is plenty of activity elsewhere at apache involving committers
> > with links to sun. see for example
> > http://incubator.apache.org/projects/river.html,
> > http://db.apache.org/jdo/, http://shale.apache.org/ (i could do on but
> > won't). however, i'm not sure how many of those work on apache code as
> > part of their job.
>
> That was my point. To the best of my understanding very few if any Sun
> employees contribute to Apache/Jakarta projects.

i know of a reasonable number but i'm not sure how many of these are
employed by sun to work on these projects full time. apache is a good
forum to develop applications which balance contributions between
different corporations. sun still contributes to a number of these and
has a long history of supporting apachecons, donating hardware and so
on.

> Sun employees
> contributing to the FOSS java world are doing so via java.net or what
> ever that's called.

AIUI that's the primary mechanism by which sun develops the community
open source it leads. it's somewhere between apache and eclipse in
social organization but is run by sun.

> Pretty sure it's not part of the JCP but might be.

AIUI the JCP is a an organisation founded by sun but run at arm's
length. decisions are taken by two committees representing the
membership. there are elections but the structure favours incumbents
and major industrial players. apache is one of the incumbent major
players. sun has a special position in that it is a permanent member
and has a veto.

membership is free to individuals. corporations pay.

the JCP did not start out as a particularly open organisation but has
come a long way after significant pressure by apache and others. the
JCP is in the middle of a process to re-examine the way that new
specifications are developed.

apache's position is well known to all the players. however, opinions
from other FOSS folks haven't really been heard. if people can stand
the NDAs, they could sign up as members and work inside the system or
just make a noise (sun is really focussed on GNU/linux ATM).

> > J2EE1.4 (2.4) RI contains tomcat but i don't think there's a separate
> > RI for the servlet container specification
>
> Ok, then Tomcat is the reference up to Servlet API 2.4/JSP API 2.0.
> Still pretty sure that is not the case for Tomcat 6.x Servlet API
> 2.5/JSP API 2.1.

the RI for 2.5 is glassfish

> > > Seems there were some differences there amongst developers, and it has
> > > been pretty much completely severed.
> >
> > most of the 3.x/4.x tomcat developers have moved onto new open source
> > projects. i don't know of any who are working on servlet containers
> > anymore outside apache.
>
> Like other containers? Resin, Jetty, etc?

nope - new topics or new languages :-)

> > > I also noticed in glassfish some
> > > sun-commons stuff, so not sure if they are duplicating that as well.
> >
> > most likely that's just part of their effort to open sourcing most of
> > their code base
>
> No it seems to me to be a result of the fork. Now there will be apache
> commons stuff and sun commons stuff.

not sure i'd really describe it as a fork but i'll not push this point

> > the fork really happened back with the tomcat 3.0 donation. the apache
> > implementation has been independent since then.
>
> No there has been another much more recent fork. Although I am not sure
> how much is out in public space. Seems there is a current dispute over
> licenses and etc wrt to Harmony
> http://www.pcworld.com/article/id,130574/article.html

the harmony's story is quite different. sun won't offer apache open
source compatible terms. apache is a charity and can only ship open
source. sun should have know this.

> Just to show recent and current rifts. How deep this goes, hard to say,
> but seems.
>
> Seems this stuff started long ago though
> http://www.internetnews.com/dev-news/article.php/10_998071

this is the original apache-sun agreement over the JCP. it took apache
a long time to convince sun that they needed open source.
http://java.sys-con.com/read/286924.htm is good from the JCP
perspective.

though it's sometimes a long hard road, sun does listen. now
(http://java.sys-con.com/read/299987.htm) is a good opportunity for
the wider FOSS community to influence the development of the JCP.

- robert
-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] Want to affect how JSRs are developed?

[Dalibor Topic]

robert burrell donkin wrote:

> apache's position is well known to all the players. however, opinions
> from other FOSS folks haven't really been heard. if people can stand
> the NDAs, they could sign up as members and work inside the system or
> just make a noise (sun is really focussed on GNU/linux ATM).

Let's not get too excited: The work on the next version of the JCP is 
already underway, being carved out behind closed doors between Sun, IBM, 
Intel, Google, Apache, and the rest of the aristocracy.

Signing up now to make noise? You'll all make your merry deals without 
us being able to influence them, anyway, like you all did before. This 
current JCP system is the one created by 'the Apache compromise', after 
all, and no one asked for our input back then, either.

What we can do, is to make sure that come next elections we know for 
sure what everyone's deeds, rather than pretty talk, are on the JSRs 
they lead, and make sure that those organizations that don't have a 
clean slate (i.e. open source RI, open source TCK, creative commons 
licensed spec, open mailing list, wiki, svn, and all that) on *all* 
their JSRs don't get re-elected onto the EC, and hopefully someone 
interested in fixing the system does.

How about that?

cheers,
dalibor topic
-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] Want to affect how JSRs are developed?

[Dalibor Topic]

Dalibor Topic wrote:

> How about that?

I should explain why the tone I used was rather harsh & cynical (and 
apologize for it).

The suggestion to join and make noise inside the JCP is not realistic 
for a couple of reasons:

* the JCP has no venue in which such noise can be made

* the JCP has two executive committees (ECs), one for mobile Java, one 
for the rest, which more or less serves as the playground for big 
politics inside the JCP between organizations.

* The ECs get to decide, behind closed doors, what the next version of 
the JCP will look like.

* i.e. unless you are on the EC of the JCP *right now*, you have no say 
in the matter, no matter if you join the JCP tomorrow and sign off NDAs 
or not.

* other than being able to vote off a small part of the EC members in 
the yearly elections,
the membership has no way to formally influence the direction where the 
JCP is going.

* so, other than joining in droves in order to kick out the EC 
establishment, there is nothing that joining the JCP would achieve.

* and the success of that would be rather questionable ... one can't 
force organisations like IBM, Apache, Sun, etc. to commit to 100% 
transparency. They'll simply move somewhere else to make their deals.

* no one can force the spec leads to do the right things, even if the 
whole EC was replaced instantly.

In practice, the current JCP system allows the spec leads to run a 
perfectly transparent JSR, with an open source implementation, TCK and 
specs without clickthoughs, like Doug Lea did for the concurrency JSR. 
The problem is that only a handful of spec leads are able to make such 
things happen.

Fortunately, there has been a recent strong trend among spec leads to 
work towards transparency, though, and in general there has been a trend 
towards open source RIs. I see the current results of the java.net poll 
as a confirmation for those spec leads that they are moving in the right 
direction, and I'm very happy to see them lead by example, and work on 
turning the system around from the inside.

I don't think that the confrontational 'let's make noise inside the JCP' 
approach would work for us who aren't on the EC, and that's pretty much 
everyone.

What works, in my experience, is changing the environment from the 
outside in which the JCP EC and its members operate, such that their 
interests and the interests of the Java & GNU/Linux communites are more 
closely aligned, and encouraging good behaviour.

It would help if more JCP members started leading by example, and made 
sure that all the JSRs they participate in have open source RIs, open 
source TCKs, etc. In that regard ASF could have a role to play inside 
the JCP in assisting companies that have close ties to it via its 
membership in the transition, and providing them with advice & guidance 
on opening up their JSRs.

The ASF could also try to make 'noise' inside the system, but I fail to 
see how that could lead to a useful outcome. I'd rather suggest that the 
ASF gets going working on creating open source TCKs for all RIs 
implemented under its spec leadership (the whole XML & WS-* stuff, 
Tomcat, and all that).

cheers,
dalibor topic
-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] Want to affect how JSRs are developed?

[robert burrell donkin]

On 4/25/07, Dalibor Topic <robilad@kaffe.org> wrote:
> Dalibor Topic wrote:
>
> > How about that?
>
> I should explain why the tone I used was rather harsh & cynical (and
> apologize for it).

(and apologies for my grammatical obscurity: i meant to suggest either
make noise about the right future direction for the JCP, or join up
and vote. still, at least my mistakes produced some interesting
comments.)

<snip>valid points</snip>

> * no one can force the spec leads to do the right things, even if the
> whole EC was replaced instantly.

this one is solvable. spec leads just need to be forced to issue
public licenses up front at the start of the process rather than
relying on hub-and-spoke contracts with participants.

> In practice, the current JCP system allows the spec leads to run a
> perfectly transparent JSR, with an open source implementation, TCK and
> specs without clickthoughs, like Doug Lea did for the concurrency JSR.
> The problem is that only a handful of spec leads are able to make such
> things happen.

+1

> Fortunately, there has been a recent strong trend among spec leads to
> work towards transparency, though, and in general there has been a trend
> towards open source RIs. I see the current results of the java.net poll
> as a confirmation for those spec leads that they are moving in the right
> direction, and I'm very happy to see them lead by example, and work on
> turning the system around from the inside.

+1

> I don't think that the confrontational 'let's make noise inside the JCP'
> approach would work for us who aren't on the EC, and that's pretty much
> everyone.

+1

but FOSS people setting out better ways to run standards processes may
well make a difference. in particular, the downstream perspective is
completely missing from the current debate.

> What works, in my experience, is changing the environment from the
> outside in which the JCP EC and its members operate, such that their
> interests and the interests of the Java & GNU/Linux communites are more
> closely aligned, and encouraging good behaviour.
>
> It would help if more JCP members started leading by example, and made
> sure that all the JSRs they participate in have open source RIs, open
> source TCKs, etc. In that regard ASF could have a role to play inside
> the JCP in assisting companies that have close ties to it via its
> membership in the transition, and providing them with advice & guidance
> on opening up their JSRs.

all that's needed is a good, well explained model: it's doesn't need
to be apache doing the talking or done in private. almost anyone who
has been deeply involved with an open source project (or the IEFT or
W3C) for a number of years could mentor a specification lead about
running a successful an open process.

> The ASF could also try to make 'noise' inside the system, but I fail to
> see how that could lead to a useful outcome.

apache's been doing this for the most part of a decade with only mixed success

> I'd rather suggest that the
> ASF gets going working on creating open source TCKs for all RIs
> implemented under its spec leadership (the whole XML & WS-* stuff,
> Tomcat, and all that).

i can't find any spec lead by apache on http://www.jcp.org/en/jsr/all

i agree that there are many specifications which were and are strong
influenced by apache ethos. apache has also been home to a lot of
reference implementations. but this is personal, not official.

- robert
-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] Want to affect how JSRs are developed?

[Dalibor Topic]

robert burrell donkin wrote:
> On 4/25/07, Dalibor Topic <robilad@kaffe.org> wrote:

>> * no one can force the spec leads to do the right things, even if the
>> whole EC was replaced instantly.
> 
> this one is solvable. spec leads just need to be forced to issue
> public licenses up front at the start of the process rather than
> relying on hub-and-spoke contracts with participants.

Good idea, but in practice nothing prevents a spec lead from having 
further license arrangements on their output, afaict, so I don't think 
that hub-and-spoke contracts will go away (or that spec leads would want 
to limit their own licensing options that way, in general).

I'd suggest advancing that idea on the merit of clarity of legal 
arrangements around a JSR, rather than as a means of forcing the spec 
leads to behave in a specific way.

>> I don't think that the confrontational 'let's make noise inside the JCP'
>> approach would work for us who aren't on the EC, and that's pretty much
>> everyone.
> 
> +1
> 
> but FOSS people setting out better ways to run standards processes may
> well make a difference. in particular, the downstream perspective is
> completely missing from the current debate.

That's correct, but I don't think that the EC membership has so far 
cared that much about the perspective outside their own organizations 
... yet.

That's not a particular surprise, since people on the EC will largely 
push the agendas of the organizations they belong to, after all they are 
(for the most part) paying for the privilege of getting their products 
turned into standards, and being able to influence the standardization 
process.

There is a simple fix, though: Sun seems to have figured out that 
cooperating with downstreams can be benefitial for them, and that 
cooperation will likely lead to some benefits for Sun in terms of how 
ubiquitous their technologies will be deployed/deployable downstream, as 
the downstreams really like Free Software & transparency and all the 
other sane engineering stuff.

The way Sun goes is the way the rest of the EC will follow, if it turns 
out to work for Sun.

Proposals to change the JCP process have been discussed regularly 
outside the JCP, but in general have not resulted in changes of the 
processes. We could speculate why that's the case, but afaict, directly 
changing specifics of the process from outside does not really work. One 
can discuss ideas to do things in a better way, but at the end of the 
day it's up to the spec leads to adopt them or not.

I'd suspect that the main reason for the lack of adoption of proposals 
to improve the JCP from outside the process comes from them being made 
outside the process, rather than by those inside the process.

So I think it's more effective to have positive feedback for JSRs run 
reasonably, than to try from outside to teach spec leads how they should 
run their JSRs, or to force them to do specific things.

What works is the 'market' supporting the specs that are well done, and 
ignoring those that aren't. Ignoring intransparently run JSRs is cheap 
and easy, and they ignore us anyway, so no harm done.

>> I'd rather suggest that the
>> ASF gets going working on creating open source TCKs for all RIs
>> implemented under its spec leadership (the whole XML & WS-* stuff,
>> Tomcat, and all that).
> 
> i can't find any spec lead by apache on http://www.jcp.org/en/jsr/all

My apologies for that assertion, I was mistakenly under impression that 
the ASF was leading specs, rather than individual companies whose spec 
leads happen to be ASF's members.

> i agree that there are many specifications which were and are strong
> influenced by apache ethos. apache has also been home to a lot of
> reference implementations. but this is personal, not official.

Is the reasoning why the ASF has been home to a lot of reference 
implementations without being the home for their test suites documented 
somewhere? I'm curios what motivates the persons using Apache as the 
home for their RIs to not develop their TCKs inside Apache.

cheers,
dalibor topic
-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] Want to affect how JSRs are developed?

[robert burrell donkin]

On 4/26/07, Dalibor Topic <robilad@kaffe.org> wrote:
> robert burrell donkin wrote:
> > On 4/25/07, Dalibor Topic <robilad@kaffe.org> wrote:
>
> >> * no one can force the spec leads to do the right things, even if the
> >> whole EC was replaced instantly.
> >
> > this one is solvable. spec leads just need to be forced to issue
> > public licenses up front at the start of the process rather than
> > relying on hub-and-spoke contracts with participants.
>
> Good idea, but in practice nothing prevents a spec lead from having
> further license arrangements on their output, afaict, so I don't think
> that hub-and-spoke contracts will go away (or that spec leads would want
> to limit their own licensing options that way, in general).
>
> I'd suggest advancing that idea on the merit of clarity of legal
> arrangements around a JSR, rather than as a means of forcing the spec
> leads to behave in a specific way.

legal clarity is a powerful tool

> >> I don't think that the confrontational 'let's make noise inside the JCP'
> >> approach would work for us who aren't on the EC, and that's pretty much
> >> everyone.
> >
> > +1
> >
> > but FOSS people setting out better ways to run standards processes may
> > well make a difference. in particular, the downstream perspective is
> > completely missing from the current debate.
>
> That's correct, but I don't think that the EC membership has so far
> cared that much about the perspective outside their own organizations
> ... yet.

one reading of history would be that the EC inducted into it's number
those organisations they discovered they needed to care about. not
sure that i believe that this is the truth or that the participants
would see it in those terms.

the key difference is that they have never had to care about or deal
with downstream organisations before

<snip>some good points</snip>

> I'd suspect that the main reason for the lack of adoption of proposals
> to improve the JCP from outside the process comes from them being made
> outside the process, rather than by those inside the process.

not sure i agree with this

my guess is that it has more to do with acknowledgment of the
necessity of change. the current process is a complex compromise which
is less than ideal for any of the parties but which most players used
to think was good enough. it's been reasonably successful in practice.

the withdrawl of JEE6 suggests that there's a wider malaise than just
the apache-sun dispute over harmony. it's often the case that
outsiders can see solutions than insiders cannot.

> So I think it's more effective to have positive feedback for JSRs run
> reasonably, than to try from outside to teach spec leads how they should
> run their JSRs, or to force them to do specific things.

but approach this is hamstrung by the fact that the JCP is short of
formal feedback mechanism. the JCP needs more confidence in itself and
open up.

> What works is the 'market' supporting the specs that are well done, and
> ignoring those that aren't. Ignoring intransparently run JSRs is cheap
> and easy, and they ignore us anyway, so no harm done.

this is easier for downstream packagers than open source implementors.
implementations have to begin before the specification is complete.
for this to work, implementors need greater legal clarity at the
outset. that way, they can ignore closed JSRs.

> >> I'd rather suggest that the
> >> ASF gets going working on creating open source TCKs for all RIs
> >> implemented under its spec leadership (the whole XML & WS-* stuff,
> >> Tomcat, and all that).
> >
> > i can't find any spec lead by apache on http://www.jcp.org/en/jsr/all
>
> My apologies for that assertion, I was mistakenly under impression that
> the ASF was leading specs, rather than individual companies whose spec
> leads happen to be ASF's members.

i can only think of a handful which were actually lead by apache
members at the time when they were members

> > i agree that there are many specifications which were and are strong
> > influenced by apache ethos. apache has also been home to a lot of
> > reference implementations. but this is personal, not official.
>
> Is the reasoning why the ASF has been home to a lot of reference
> implementations without being the home for their test suites documented
> somewhere? I'm curios what motivates the persons using Apache as the
> home for their RIs to not develop their TCKs inside Apache.

my guess is that there isn't a single answer to this question and that
motivations vary with time

a few years ago, it wasn't really possible to develop JSRs within
apache: projects are not allowed to discriminate between those
committers who have signed NDAs and those who have not. so, mostly RIs
were donated at the end of the process. my guess is that the TCK
remained closed either to preserve revenue streams or just through
inertia.

it is now possible to create a specification within apache (see
http://db.apache.org/jdo/) using open methods. in this case, the TCK
and specification were homed at apache and the RI at codehaus. maybe
this implies that there is some sort of operational advantage in
splitting RI from TCK teams.

- robert
-- 
gentoo-java@gentoo.org mailing list