On Mar 19, 2004, at 4:52 PM, Henri Yandell wrote:
I'm still in disagreement. I'm founding a lot of this on the idea that
Groovy is a good fit for a JSR. There's no reason for more than one
implementation to exist that I can think of and there's no reason why an
open-source project would be hurt under a JCP process. Both big leaps.
Suppose that BEA wants to embed the language in their app server stack, and for whatever reason they want to re-implement for monitoring or to limit what program someone can execute....
When you say "under a JCP process" what do you mean?
Formally, it means that someone proposes a project (just like now to incubator, their peers or a PMC I suppose), and a panel of judges (the Exec committed) decides if it can go forward.
An expert group then meets and works on the spec, offering it for public comment, and then producing a final spec, a TCK and a RI.
What part are you missing in your life?
Everyone seems to assume that the JCP.org exists to create specifications
for other people to implement. I assumed that.
It exists to create specifications. You could implement the spec, or if the business terms are acceptable to you, reuse the RI as the implementation, under whatever loony license the spec lead decides.
However, I see no reason why Groovy fits under that assumption, and so I wonder what else Groovy will get from being within the JCP.
In no order :
1) If you are opposing my 'yes' vote on the part of the ASF, speak now. My official motivation for the 'yes' vote is that I believe that it would be a good addition to the Java universe (and at worst, not a harmful one) and more importantly is a OSS project from EG to license to TCK and RI and may even use the ASF's proposed TCK and RI licenses.
2) It's not an ASf project, so anything we say here about the motivations of the Groovy team are sheer speculation. (FD - I'm a member of the EG)
Groovy will get a formal spec protected by the compatibility requirements of the JCP. It will also get some vague status of 'officialdom' although I have no clear idea what that really means.
Also, much of the JCP must be generic,
towards developing a product and not towards a specification. TCK = unit
tests? RI = binary? Spec = Docs?
Not at all. Nothing close actually. Take JavaMail. the only reason why someone would re-implement is because Sun's binary license is so stupid. Other than that, it's good to have a standard that anyone can use.
Docs aren't a spec. A doc tells you how to use. A spec tells you what will happen when you use it, and in very particular and careful ways. My hats off to Richard for undertaking the spec writing responsibility for Groovy.
We already effectively have Expert Groups, we call them the PMC. Project
Leads, aka active-voice on the project/component. I'm not sure it hurts
for us to have a project-lead on things, in fact I think it's something
Apache should have. Defined responsibility.
That notion is actually contrary to the way Apache projects are to run, although it happens all the time, and I agree with you it's a good thing. However, it's not a formal thing, nor will it be.
The codehaus way is different, where there is a project lead who has a significant say.
It's too early to tell if one is better than the other. The ASF is successful, but it's been my observation that the codehaus way is how may projects run naturally, and a strong lead has precedent in OSS - like RMS and Linus Torvalds.
People view this as anti-community, but I think it's pro-community. Who is
responsible to the community for Tomcat 3 at the moment? The community?
That seems like we're kidding ourselves. The ASF-way merely means that
it's easy to fill a project-lead gap, or to join in. Not that the
project-leads don't exist.
There are problems with the JCP system [unsure if 2.6 changes anything].
One big problem/difference is [I've heard anyway] that the project lead
has dictatorial powers. I'm not suggesting we ingest the bad water with
the good.
didn't you just state only 1 paragraph ago that you thought it good to have a defined lead?
Yes, 2.6 does changes things, but tangibly and intangibly.
And yes, the lead has dictatorial powers if the lead wants it. Given that companies are spending big $ and contributing their IP to some of these JSRs, it's hard to imagine that they wouldn't demand control.
However, there is no requirement that the lead be a dictator, and the Groovy JSR will show that OSS style consensus with strong lead works.
Anyway. That's the basis of my questionsuggestion. Why [apart from
non-Java Apache political reasons] would a [EMAIL PROTECTED] process, built on
the JCP [with changes we want to enact in the JCP] be such a horrid idea?
It's designed for a different purpose, and what we have works really, really well :)
Bear in mind. It's the end of the week, and this is a typical over a table
of beer question :)
Except I don't have a beer at the moment...
geir
Hen
On Fri, 19 Mar 2004, Geir Magnusson Jr wrote:
On Mar 19, 2004, at 1:44 PM, Noel J. Bergman wrote:
How about if Jakarta [or Apache-Java as a whole] embraced the latest JCP process?
In what way? Can you be specific? As I understand the JCP, what you are asking makes little sense.
We don't have "spec leads", nor do we want them. We don't have ownership of a project/specification. Everything here is communal and consensual. That is not true of the JCP. Actually, I would prefer to see the JCP continue to evolve to become more like the ASF.
What I'm largely interested in are the reasons why not, as these would be perfect reasons why something like groovy, or ant or httpclient, should not become jsr's.
A JSR is a specification. It should have a TCK and an RI, but at
heart it
is a specification. Some people have talked about proposing the Apache
Repository Specification, which I understand Maven will evolve to use,
as a
JSR. If that happened, I'd prefer to see us run a JCP Expert Group
more in
line with an ASF project, not run ASF projects like an JCP Expert
Group.
That would be a good example of something that would be appropos for a
JSR - something that others will/might implement, and if so, you want
to be sure that your software which works with one implementation of it
works with others.
Geir? Your thoughts?
We are always working to help move the JCP towards the OSS model, but
it's a slow process. In JCP 2.5 (the guidelines for the JCP), the
ASF's work was key in getting TCKs and RIs to be able to be licensed
under and OSS license. Before that, there was no way to do an OSS JSR.
Now, w/ 2.6 that just went into effect last week, the process now
formally encourages as much openness and transparency as possible in an
EG (although you still can do pretty much what you want...) as well as
require an early release of the spec to the community to enable as much
feedback and commentary as possible. Previously, the EGs had to
release a community draft late in the process, and that made them
afraid to have not enough time to fix stuff, so they would tend to
really delay.
The Groovy EG will be run as an OSS project, btw...
geir
--- Noel
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED]
--------------------------------------------------------------------- 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]
-- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
