However, I'm not sure that I understand your suggestion about Jakarta Commons becoming top level, and then being joined by Apache Commons. I think it should be the other way around -- Jakarta Commons projects should become Apache Commons projects.
But in a sense, it can all seem redundant. If Apache Commons then has projects for all languages, there would need to be at least a small separation of projects by language, if only for web site listing, or coding standards, etc. So, there would be a Java branch of Apache Commons -- which is kind of what Jakarta was in the first place, Apache's Java project, right?
So, my point is, I agree that Jakarta Commons might benefit in being higher up. I'm surprised that Struts isn't a top level project already, but if it were to be, then that would be another top level project that depends on JC -- which doesn't quite fit with the charter.
Although, as I just mentioned, the language issues still confuse me.
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]
