Return-Path: Delivered-To: apmail-incubator-general-archive@www.apache.org Received: (qmail 77248 invoked from network); 30 Dec 2005 21:28:02 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 30 Dec 2005 21:28:02 -0000 Received: (qmail 13241 invoked by uid 500); 30 Dec 2005 21:28:00 -0000 Delivered-To: apmail-incubator-general-archive@incubator.apache.org Received: (qmail 13195 invoked by uid 500); 30 Dec 2005 21:28:00 -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 13184 invoked by uid 99); 30 Dec 2005 21:28:00 -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 13:28:00 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of craigmcc@gmail.com designates 64.233.162.205 as permitted sender) Received: from [64.233.162.205] (HELO zproxy.gmail.com) (64.233.162.205) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 30 Dec 2005 13:27:59 -0800 Received: by zproxy.gmail.com with SMTP id l8so1272254nzf for ; Fri, 30 Dec 2005 13:27:38 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references; b=unB9x1T/sB5PSZ4fm9bZNti+oPsUB2bpaZIXk0kQEBikjIcr4/TUanEqCIpZQSLcaVEcJUbDWOF+WX6aTEoU7u9bu+zS+z56QCW3pO5x6YpNohMUDhrlL+COebOgzxdSU5QehfXQGgy9cib6yZaS5ka327CwP0R9KDzpsMrnZGo= Received: by 10.64.149.14 with SMTP id w14mr4360396qbd; Fri, 30 Dec 2005 13:27:38 -0800 (PST) Received: by 10.65.15.17 with HTTP; Fri, 30 Dec 2005 13:27:38 -0800 (PST) Message-ID: Date: Fri, 30 Dec 2005 13:27:38 -0800 From: Craig McClanahan Sender: craigmcc@gmail.com To: general@incubator.apache.org Subject: Re: Starting a java specs project In-Reply-To: <43B56AF9.1070902@apache.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_75096_28290896.1135978058607" References: <000301c60d4b$6669b5f0$6801a8c0@CARMANI9300> <43B56AF9.1070902@apache.org> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------=_Part_75096_28290896.1135978058607 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 12/30/05, Alan D. Cabrera wrote: > > Looks good to me. > > Guys, should we not begin to create a specs project in Jakarta? It > seems that we have a consensus. Well, maybe ... I have a couple of concerns about the practicalities here. First, at least for the set of standards that are JCP related (non-JCP standards will likely have a similar set of issues, however), let's divide the world of specs we might be interested in having API classes around for into two groups (a) JSRs that Apache also hosts implementations for (MyFaces, Tomcat, Geronimo, Pluto, a bunch of the web service ones, etc.) (b) JSRs that Apache does not host implementations for, but where projects might want to rely on implementations acquired elsewhere. For group (a), the current practice is to host the API classes inside the project that is also providing the implementation. That makes sense to me for a number of reasons, but the most important ones revolve around ensurin= g that the produced classes comply with the corresponding TCK tests to ensure spec complance. The people most familiar with the requirements, and the most motivated to watch for potential compliance-breaking changes, will be the folks doing the corresponding implementation. Even in the current situation, it's really easy for a committer to try to tweak API classes in = a manner that will not be compatible ... but these cases get caught quickly, because the "in the know" developers are going to be watching. Note that if a primary goal of this effort is to have a common repository o= f API jars (and that's certainly a worthy goal), it doesn't require a separat= e project to accomplish that -- simply a mechanism for cooperation on what repository to post API jars into. (However, even there, we'd need to check licensing in each case whether the API jar can be published separately.) For group (b), the latter consideration will also apply -- the API classes for a JSR are licensed as described in each individual JSR. If a primary goal of this effort is to encourage the development of a community interested in the general issues of implementing Java based standards (also a worthy goal), that's great ... but it does not seem to me that sharing API code is a prerequisite for accomplishing this. Craig What are the next steps? > > > Regards, > Alan > > On 12/30/2005 6:14 AM, James Carman wrote: > > >Why not do like we do with the commons? > > > >spec-javamail > > > > > > > >-----Original Message----- > >From: Henri Yandell [mailto:flamefew@gmail.com] > >Sent: Friday, December 30, 2005 9:08 AM > >To: general@incubator.apache.org > >Cc: jcp-open@apache.org > >Subject: Re: Starting a java specs project > > > >On 12/27/05, Hiram Chirino wrote: > > > > > >>Hi, > >> > >>I think this would be great! I know it's silly, but I get annoyed at > >>the fact that many of the J2EE spec jars that I use from apache have > >>"geronimo-" in the jar name but It's just the ASL 2.0 spec jars that > >>I'm using and not really a geronimo implementation. In general, I > >>think that this would make a good TLP since it would provide a good > >>area for cross project involvement. > >> > >> > > > >[presuming it was stored at Jakarta Specs] > > > >Do you think they should be apache-xxxx or jakarta-xxxx, or either > >would be fine? > > > >Would 'jakarta-spec-javamail' be too much of a mouthful? > > > >Hen > > > >--------------------------------------------------------------------- > >To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org > >For additional commands, e-mail: general-help@incubator.apache.org > > > > > > > > > > > ------=_Part_75096_28290896.1135978058607--