incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <>
Subject Re: Starting a java specs project
Date Fri, 30 Dec 2005 22:49:12 GMT
On 12/30/2005 1:27 PM, Craig McClanahan wrote:

>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.

There's an interesting idea.  So there is a shared repo destination that 
all the respective projects public spec jars into?  I would imagine that 
we would need some convention published in each project so that the spec 
jars can easily be found.

Can you elaborate on your statement "we'd need to check licensing in 
each case whether the API jar can be published separately" since I am 
unaware of any such restrictions?


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