On 12/30/2005 1:27 PM, Craig McClanahan wrote:
On 12/30/05, Alan D. Cabrera <[EMAIL PROTECTED]> 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 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?
Regards,
Alan
