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]
