From: "Morgan Delagrange" <[EMAIL PROTECTED]> > Given a choice, I'd rather just stay put at Jakarta. > However, I forsee a time (possibly very soon) where we > are faced with either a) lobbying for top level > project status, or b) voting on dividing individual > components between a-c and j-c. To the latter, I'm > staunchly opposed. Remaining part of the Jakarta > community is not as important to me as preserving the > j-c community itself. I don't want us to end up on > the rocks over issues of governance and ownership.
I agree that dividing j-c on a per individual component basis would be something to be opposed. However, equally, I don't think that j-c is quite such a single entity as it started out as. My preferred option would be: JavaCore - top level project in Java & Library federations (Lang, Collections, IO, Pattern, Util, BeanUtils) XMLJavaCore - top level project in Java, XML & Library federations (xml-commons, Digester, Betwixt, JXpath) NetworkJavaCore - top level project in Java, Network & Library federations (HttpClient, Net) JavaCommons - top level project in Java & Library federations (Jexl, CLI, DBPool, Latka...) (Library is renamed apache-commons, as a federation not a project) This division represents a reasonable split of current j-c committing practices. People interested in more than one can join more than one of course ;-) People not, don't. But the communites are not so small as to collapse through inaction as they are more than one 'component'. Stephen
