The Jakarta brand may be interpreted to be: "web-based server-side code". It's definitely not [EMAIL PROTECTED] anymore.
It's only [EMAIL PROTECTED] in the same way that people thought Jakarta==Tomcat and Jakarta was separate from ASF. Xerces is a very good example of a group who could happily be gaining from the a same-function mailing list, and yet their community has chosen not to share one mailing list [I assume]. So a good argument for us to use for some language separation between Commons'es. Hen On Fri, 19 Dec 2003, Dirk Verbeeck wrote: > I agree with the statement that the Jakarta Commons charter needs an > update and there is also nothing against becoming a TLP and reporting > directly to the board. > > But we should keep the Jakarta brand. Jakarta as the main java entry > point at Apache and as a provider for the java news/download is > important I think. (see also [EMAIL PROTECTED]) > > I think a lot of people think "Jakarta" when you ask for java from > apache. The jakarta-commons is then a logical place for all reusable > java components. (and yes I think the java components in db-commons > would benefit from moving to jakarta-commons) > > As for other languages joining, look at xerces. > They have separate mailing list for each language. > So the simplest split would be: > commons-j-dev => jakarta-commons > commons-c-dev > commons-p-dev > > For starting up new cross language initiatives a better medium can be > found. A shared wiki, newsletter, ... > > Once a component has multiple implementations in multiple languages it > is probably large enough to become a TLP itself (like log4j). > > > -- Dirk > > > Henri Yandell wrote: > > > [partially fantasy land/future ideas] > > > > The Jakarta Commons charter basically views Commons as a supplier of > > Jakarta projects, and not Apache projects in general. > > > > With many of the Jakarta sub-projects moving to TLP status [ie) > > ant.apache.org etc], this is increasingly untrue. Jelly's main customer > > is Maven for example, quite a few XxxxUtils classes in Commons came from > > Ant, and a lot of code came from a partial merger with Avalon's Excalibur. > > > > There are two easy solutions [to think of]. The first is to change the > > charter to match reality, ie) any ASF TLP is considered a client of > > Jakarta Commons. The other is for Jakarta Commons to become a TLP. > > > > I'd like to speak for the latter suggestion, I'd also then like to suggest > > a more radical [flame-likely], though obvious next step. > > > > Pluses I see for becoming a TLP: > > > > * Currently we're viewed as a bit of an odd project in that we're an > > umbrella project child of an umbrella project. Removing one of these > > layers will improve the view that we have strong awareness of what's going > > on and we would report directly to the board. > > > > * It helps get us into the ASF community. We're a bit hidden away from new > > TLP Java projects, such as the currently incubating Directory project, and > > a TLP placement would lead to more involvement and a larger community > > spread as new Java projects arrive there. > > > > * There's community interest in a TLP Commons, and as a community we have > > a large amount of knowledge we can bring to the table. > > > > The last point suggests an obvious next step, which is some kind of > > merging with the Apache Commons project. I would like to suggest that the > > way we do this is that, J-C goes to TLP, with all its current rules and > > community, A-C projects join J-C [currently just Serf, though a > > *libtool project that's something to do with compiling C is likely to join > > A-C too], J-C removes its Java-centric view and allows any language to > > join. > > > > The things I believe we should push for is that our current J-C group > > should not try to de-java ourselves, but that we allow the A/J-C community > > to choose its own delineations over time and not try and set them up to > > begin with. Our mail lists would stay the same and they would join, and > > over time we would decide, much like httpclient in the past, whether we > > need new mail lists. > > > > The PMC for such a thing would be based on all active committers, so no > > real change than the current way in which the J-C bazaar is handled. > > > > I think the ASF infrastructure group are going to want ASF projects to be > > using subversion rather than cvs at some point in the future, and the > > current A-C community has good subversion understanding with which to help > > us if that should come to pass. > > > > There are also obvious ties when similar domain products, serf/httpclient, > > are able to communicate more openly and easily. > > > > --- > > > > Does anyone have any negatives/positives of such a thing? Does it make any > > sense for the future? Does it harm/help J-C? > > > > Or am I just suggesting evil thoughts? > > > > Hen > > > > > --------------------------------------------------------------------- > 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]
