On 3/5/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > > > > On Sun, 5 Mar 2006, Martin Cooper wrote: > > > On 3/5/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > >> > >> Why restrict a project? > > > > > > One of your big things right now - order and organisation. ;-) > > Guess I don't see this as one that needs constraining - how a > component/subproject does something - sure. What it's allowed to do - > nope. Not as long as it falls within the larger Jakarta charter.
It's not so much what it's "allowed" to do, as much as to define its purpose. Perhaps you see Velocity as a viable Commons component, but I don't. Nor do I think it would make sense for Digester to be part of Cactus, or Taglibs to be part of Slide. A well-defined scope is a good thing, and helps people understand what they're looking at. >> I missed the alternative on this email (it spun out of a Commons email) > >> which is why don't we require these of all subprojects? > > > > > > I can't answer the question, but that would be fine with me. > > Seems like unnecessary bureaucracy. It's not bureaucracy. See above. >>> Say some Prolog constraint framework decided it wanted to be part of > >>> Commons. Where would you point them to explain that that's not what > >> Commons > >>> is about? > >> > >> The Jakarta charter where it says Java (which in fact it doesn't say - > >> might be a bit of an ommission). > > > > > > OK, then what about a Java constraint framework? > > If it's large: -1 to Commons, -1 to Jakarta. If it's tiny +0 to Commons, > +1 to Jakarta, but they're converging to both be a +1 if not too framework > like. I specifically chose a framework for my example because we have long stated that frameworks should not live in Commons, and that is stated in our charter. Are you saying you want to change that now, to allow frameworks as Commons components? I so, -1 from me. -- Martin Cooper > Here's the Commons Charter: > >> > >> *************************************** > >> 0) rationale > >> > >> <history, then:> > >> A Jakarta subproject to solely create and maintain > >> independent packages is proposed to accelerate and guide this process. > >> > >> (1) scope of the subproject > >> > >> The subproject shall create and maintain packages written in the Java > >> language, intended for use in server-related development, and designed > to > >> be used independently of any larger product or framework. Each package > >> will be managed in the same manner as a larger Jakarta product. > >> > >> <bit about sandbox> > >> > >> (2) identify the initial set of committers > >> > >> <historical list> > >> ****************************************** > >> > >> If anything, that's a better Jakarta charter than the Jakarta charter > and > >> should be merged in - but there's very little to restrict the scope of > >> Commons. > > > > > > Well, I see: > > > > * Written in Java. > > +1 to this in the Jakarta charter - though I'd probably say 'Written for > Java'. Commons Daemon has C parts, but exists for the purposes of Java. > > > * Independent packages. > > Common sense - assuming it means other people wouldn't use their packages, > but fine to add to the Jakarta charter. If it means no dependencies, well > we break this one a lot. > > > * Intended for server-side. > > +1 to this in the Jakarta charter. We've always had this as a loose > constraint. We don't interpret this as server-side though, rather we > interpret it as not client-side. > > > * Not frameworks. > > +1 to this in the Jakarta charter - we're heading that way. > > > Those don't all apply to Jakarta as a whole, but they do all apply to > > Commons, and I, for one, do not want to lose those statements of scope > and > > purpose. It's a charter, whether or not you want to call it one. > > So my disagreement is that I think it should apply to Jakarta as a whole - > and is pretty close to doing so. > > Hen > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
