From general-return-6905-apmail-incubator-general-archive=incubator.apache.org@incubator.apache.org Fri Dec 30 18:29:58 2005
Return-Path:
Delivered-To: apmail-incubator-general-archive@www.apache.org
Received: (qmail 8416 invoked from network); 30 Dec 2005 18:29:56 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
by minotaur.apache.org with SMTP; 30 Dec 2005 18:29:56 -0000
Received: (qmail 22855 invoked by uid 500); 30 Dec 2005 18:29:55 -0000
Delivered-To: apmail-incubator-general-archive@incubator.apache.org
Received: (qmail 22466 invoked by uid 500); 30 Dec 2005 18:29:53 -0000
Mailing-List: contact general-help@incubator.apache.org; run by ezmlm
Precedence: bulk
List-Help:
List-Unsubscribe:
List-Post:
List-Id:
Reply-To: general@incubator.apache.org
Delivered-To: mailing list general@incubator.apache.org
Received: (qmail 22452 invoked by uid 99); 30 Dec 2005 18:29:53 -0000
Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)
by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 30 Dec 2005 10:29:53 -0800
X-ASF-Spam-Status: No, hits=0.0 required=10.0
tests=HTML_MESSAGE,UNPARSEABLE_RELAY
X-Spam-Check-By: apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Received: from [192.18.98.36] (HELO brmea-mail-4.sun.com) (192.18.98.36)
by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 30 Dec 2005 10:29:52 -0800
Received: from fe-amer-06.sun.com ([192.18.108.180])
by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id jBUITVuf021325
for ; Fri, 30 Dec 2005 11:29:31 -0700 (MST)
Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com
(Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005))
id <0ISB00K01P9V9800@mail-amer.sun.com>
(original mail from Craig.Russell@Sun.COM) for general@incubator.apache.org;
Fri, 30 Dec 2005 11:29:31 -0700 (MST)
Received: from [192.168.0.10] (c-24-6-172-77.hsd1.ca.comcast.net [24.6.172.77])
by mail-amer.sun.com
(Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005))
with ESMTPSA id <0ISB00KQCQ16PA00@mail-amer.sun.com> for
general@incubator.apache.org; Fri, 30 Dec 2005 11:29:31 -0700 (MST)
Date: Fri, 30 Dec 2005 10:29:26 -0800
From: Craig L Russell
Subject: Re: Starting a java specs project
In-reply-to: <43B56F10.5010208@pobox.com>
Sender: Craig.Russell@Sun.COM
To: general@incubator.apache.org
Message-id:
MIME-version: 1.0
X-Mailer: Apple Mail (2.746.2)
Content-type: multipart/signed; protocol="application/pkcs7-signature";
boundary=Apple-Mail-204-893862115; micalg=sha1
References: <43B1681D.40201@toolazydogs.com>
<31cc37360512271912l37f3438di32a95f00f71530b1@mail.gmail.com>
<2A95CB31-C295-4BD3-BAF4-DC821D6D6FC1@apache.org>
<200512310124.18505.niclas@hedhman.org> <43B56F10.5010208@pobox.com>
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N
--Apple-Mail-204-893862115
Content-Type: multipart/alternative;
boundary=Apple-Mail-203-893860453
--Apple-Mail-203-893860453
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=US-ASCII;
delsp=yes;
format=flowed
I have a few observations that might help inform what we do here.
1. There is often what you might call "implementation" in the
javax. domain. There are bootstrap classes in the JSR 220 and
JSRs 12 and 243 that must be implemented by the javax code. And
Exceptions and Errors have to be classes. But 99% of the time, the
javax material comprises interfaces that an implementation is
supposed to implement.
2. There is no reason that I know of to restrict commit privileges on
the javax code to expert group members. The TCKs typically include
signature tests that verify that the interfaces and classes contain
exactly what they are supposed to.
3. There is ongoing maintenance on the javax code in a JSR.
Clarifications in the specification often lead to slight changes in
the implementation of classes. Less frequently, an API can be added
to a specified interface (doesn't change backward compatibility but
adds functionality).
4. Apache JDO (which notwithstanding information on the incubator web
site has graduated;-) is a project that is implementing both the API
and the TCK. It's not clear to me what the advantage is to putting
the API part in another project. Other projects that want to access
the API jar can simply reference it via maven or download the jar files.
5. The JDO spec development is done in the open via cross-posting to
the official JDO expert group alias and the apache-jdo dev alias. But
this practice is not very common; many JSRs are developed in secret.
6. The roadmap for the Apache JDO project includes an implementation
of the JDO 2 specification for relational and other databases. There
is synergy with Tomcat, Geronimo, and the DB TLPs to integrate this
future implementation into web and application servers and tools.
Craig
On Dec 30, 2005, at 9:32 AM, Geir Magnusson Jr wrote:
>
>
> Niclas Hedhman wrote:
>> On Friday 30 December 2005 22:52, Geir Magnusson Jr. wrote:
>>> I'm missing something fundamental. What would a JSR Expert
>>> Group have to do with this? We are talking about the API jars
>>> for completed JSRs, right, and maybe other specs if there are
>>> any that require similar machinations? (I can't think of any...)
>> Not sure if the JDO spec is being referenced, but that is a spec
>> +TCK project only, where a portion of th EG are ASF committers and
>> the spec development happens on the ASF infrastructure.
>
> I think it was just coming out of incubation, but yes, that's
> something we should point to somehow.
>
> It would be nice to have a JDO2 impl here as well...
>
> geir
>
>> Cheers
>> Niclas
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
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!
--Apple-Mail-203-893860453
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=ISO-8859-1
I have a few observations that =
might help inform what we do here.

1. There is often what you =
might call "implementation" in the javax.<spec> domain. There are =
bootstrap classes in the JSR 220 and JSRs 12 and 243 that must be =
implemented by the javax code. And Exceptions and Errors have to be =
classes. But 99% of the time, the javax material comprises interfaces =
that an implementation is supposed to implement.

2. There is no reason that =
I know of to restrict commit privileges on the javax code to expert =
group members. The TCKs typically include signature tests that verify =
that the interfaces and classes contain exactly what they are supposed =
to.

3. There =
is ongoing maintenance on the javax code in a JSR. Clarifications in the =
specification often lead to slight changes in the implementation of =
classes. Less frequently, an API can be added to a specified interface =
(doesn't change backward compatibility but adds =
functionality).

4. Apache JDO (which =
notwithstanding information on the incubator web site has graduated;-) =
is a project that is implementing both the API and the TCK. It's not =
clear to me what the advantage is to putting the API part in another =
project. Other projects that want to access the API jar can simply =
reference it via maven or download the jar files.=A0

5. The JDO spec development =
is done in the open via cross-posting to the official JDO expert group =
alias and the apache-jdo dev alias. But this practice is not very =
common; many JSRs are developed in secret.

6. The roadmap for the =
Apache JDO project includes an implementation of the JDO 2 specification =
for relational and other databases. There is synergy with Tomcat, =
Geronimo, and the DB TLPs to integrate this future implementation into =
web and application servers and tools.

Craig

On Dec 30, 2005, at 9:32 AM, Geir Magnusson Jr wrote:

Niclas =
Hedhman wrote:

On =
Friday 30 December 2005 22:52, Geir Magnusson Jr. wrote:

=

I'm missing something =
fundamental.=A0 What would =
a JSR Expert Group=A0 have =
to do with this?=A0 We are =
talking about the API jars for=A0 =
completed JSRs, right, and maybe other specs if there are any =
that=A0 require similar =
machinations?=A0 (I can't =
think of any...)

Not sure if =
the JDO spec is being referenced, but that is a spec+TCK project only, =
where a portion of th EG are ASF committers and the spec development =
happens on the ASF infrastructure.

I think =
it was just coming out of incubation, but yes, that's something we =
should point to somehow.