incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig McClanahan <>
Subject Re: Starting a java specs project
Date Fri, 30 Dec 2005 21:27:38 GMT
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
  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 ensuring
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 of
API jars (and that's certainly a worthy goal), it doesn't require a separate
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.


  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 []
> >Sent: Friday, December 30, 2005 9:08 AM
> >To:
> >Cc:
> >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:
> >For additional commands, e-mail:
> >
> >
> >
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message