On Fri, 19 Mar 2004, Geir Magnusson Jr wrote:
> > 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.... Pretty hypothetical. They might want to do the same for JUnit or Ant etc. I think Groovy doesn't really fit the JSR-style so far, but I think it will be a good thing if it happens as it will help to increase the JSR from simply a spec-world into something more of a central clearing house for Java concepts. > 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? Unsure. Mathematical beauty? Simplicity? I liked the idea of drawing parallels between two processes and allowing them to feed off each other and hopefully draw nearer [in terms of being more OSS friendly or more organised]. Formulate new proposals to the Apache lists in a similar manner to a new JSR and write projects up in a similar format. Have named leads and specified active-committer groups on components. Understand more about which apache-areas are active, which are actively watched and which are in a coma. > > 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. Wouldn't even if I could. I presume that opposing votes is an Apache board/member thing. I've made the point that Groovy as a JSR will be great as an OSS demo of the JCP on a jug list, so am in complete agreement there. > 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. Seems useful for many projects, so if Groovy is hale and hearty in a year, it would seem that we should ask the JSR question of any apache components that might fit. Jelly, Ant, Maven leap to mind. Probably others. > > ..... > > 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? The bit I view as important is that a lead's responsibility is to the community. Largely this is a Jakarta-blindess on my part. The lead is yourself, the PMC Chair. In other projects it's blindingly obvious, but the size of Jakarta made me not notice it. Hen --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
