That's one long term vision for Jakarta, and I think the best one. The other one that seems to have strength is a focus on Tomcat as a web-container and associated projects.
To this end, I can see Jakarta Commons going to TLP and trying to take BCEL, BSF, ORO and Regexp with it. Gump would go its own way to TLP-ness. In my fantasy world information architecture. The latter fantasy means a lack of a [EMAIL PROTECTED] place, with J-C being more of a workshop for small focused pieces. Hen On Sat, 20 Dec 2003, Dirk Verbeeck wrote: > Maybe Jarkarta should take up the role of a [EMAIL PROTECTED] gatekeeper. > Something like the java foundary at sourceforge but with the > additional task to bring all the (independent) java communities > together and provide a vision for the [EMAIL PROTECTED] future. > > -- Dirk > > > Henri Yandell wrote: > > > 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] > > > > > > > > > > > > --------------------------------------------------------------------- > 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]
