Henri Yandell wrote:
An FYI. Please kick me if I'm going too far with these ideas; I get the
feeling I have a general +0, but hard to tell sometimes.
See interspersed. I am not quite to the "+" point yet, but probably
either just missing some concepts / principles or interested in
understanding better what the alternatives are.
Hen
---------- Forwarded message ----------
Date: Tue, 27 Dec 2005 11:42:47 -0500 (EST)
From: Henri Yandell <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: [email protected]
Subject: Re: Starting a java specs project
One idea was to collate them as a part of Jakarta.
My aim for Jakarta is to either promote subprojects to TLP or flatten
them into Jakarta Commons,
The risk there is j-c becoming the new "umbrella." We are also having
enough trouble scaling j-c now.
leading to a non-umbrella Jakarta
It would be great if we could get a consensus on what an "umbrella" is
and what is bad about it. I don't want to open too many cans of worms
here; but not all of us were around for the "good old bad old days" of
Jakarta. It seems to me that all of the following could now be
considered "umbrellas" in some sense, but we (apache) seem to be
collectively OK with them:
Geronimo
Web Services
XML
Struts
DB
Logging
Portals
But somehow Jakarta is "too big." If you look at all of the code now
coming into Geronimo with the incubations in progress, it will be larger
than Jakarta currently is soon. So why exactly do we need to either
mash, e.g. Hivemind into Commons or move it to TLP? If the answer is
"PMC oversight" then why doesn't that apply to the projects above as
well? We have made a lot of progress - mostly thanks to you, Hen -
getting adequate PMC representation from all Jakarta projects, so I
don't see that as such a big concern any more.
So what problem exactly are we trying to solve by pushing things out or
mashing them into Commons? I don't mean to be argumentative here, I
just want to understand clearly what the goal is and what our acceptable
options are. It would be great to have some principles on what kinds of
"aggregates" (euphemism for "umbrellas" ;-) are OK and what kinds are
not. Based on these principles, we might decide to divide Jakarta
differently, creating some smaller aggregates rather than one big one
(j-c) and a string of small TLPs.
(I know,
you didn't think you'd see it in your lifetime). This new Jakarta would
have the potential to serve two roles:
1) Place for [EMAIL PROTECTED] to share conversation [EMAIL PROTECTED]
2) Place for [EMAIL PROTECTED] to share code [Jakarta Commons]
While j-c might have begun as 2), this is no longer the whole story, or
even the main story any more.
Storing the spec source there would be good for everyone I think; it
would help bring people to Jakarta to share code and conversation, and
the Commons community would make good stewards for the code if the
various owners departed.
We already have too much orphaned code in j-c, IMHO. The advantage of
bringing this stuff to j-c would be bringing in some more active and
engaged committers. This I am sure we would all welcome. Orphaned code
we would not.
Maintaining this code will require some specialized expertise most
likely concentrated in projects like Geronimo, Tomcat, etc. If
committers from these projects are interested and willing to sign up to
actively support the code in j-c (including responding to user
questions), I am sure we will be happy to have them join us. I would be
hesitant to volunteer the j-c community, however, as a support mechanism
without ongoing active involvement from the apache projects using the
specs, though.
Some other pluses are that it would help be a part of an attempt to
rejuvenate Jakarta in 2006 (as a kind of federation) and that non-JCP
specs could be stored there too.
Not trying to intrude on the JCP stuff though, so I can see if it's
preferred to keep things under a strictly JCP-oriented environment.
Hen
On Tue, 27 Dec 2005, Alan D. Cabrera wrote:
There has been some discussion on creating a Java specs project which
would hold all the specs jars from the various JSRs as well as other
standards, e.g. CORBA. Often, there are many duplicate "copies" of
the source code for the same JSR floating around in different Apache
projects. It would be a great idea to move them all into one
project. This idea, so far, has been met with much enthusiasm.
How do we get this started?
Regards,
Alan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
