IMHO, the Board made an error of judgement with the setting up of a-c. A desire has been expressed to have one TLP for small reusable components, which has been met with a repeated desire for a Java-centric area. (Relatively few people oppose a java based commons TLP). Some solutions I can think of:
1) j-c merges with a-c and we just have to get along. (Hen suggested a variation on how to start this, but the result is the same) 2) a-c becomes an umbrella project housing a virtually independent java commons, a C commons, etc. I don't believe the Board or existing a-c would be happy with this. 3) a-c is disbanded completely. j-c is then promoted to TLP using the Commons name, and Java only. 4) j-c merges up into Jakarta, once all the other bigger projects leave. 5) j-c is promoted to TLP using a different name, such as Commons-J. Personally I have great difficulty with #1. I believe #2 won't happen. #3 would be really nice, but would require some humility in recognising a mistake made in a-c. #5 is messy, as Commons is 'our' name before it was kindof stolen. #4 is challenging, but maybe possible. Stephen ----- Original Message ----- From: "Stephen Colebourne" <[EMAIL PROTECTED]> > I too stick with the Java-centric theme. I don't want to seem overly anti > other programming languages, its just that IMO j-c is better of as just > Java. > > a) Code standards, guidelines, packaging, naming, integration with JDK - all > are very Java specific, and are usefully captured in the charter. > > b) j-c is already very busy, and if we add BCEL and perhaps some others, > (which we probably should), it could get busier. > > c) There is no easy division within j-c. I've tried on many occasions to > find one, and always fail. However there is the potential for some to leave* > > Stephen > > > * [logging] could migrate to the new Logging TLP, especially if Avalon > LogKiy goes there. > [httpclient] and [net] could perhaps join Serf in a webdav TLP (someone > metioned this somewhere....) > > > ----- Original Message ----- > From: "Gary Gregory" <[EMAIL PROTECTED]> > > #1) Jakarta is Java Centric. > > My main disagreement is to loose the Java-centric view of the current > A-J-C. > > When I am working in language X, in this case Java, I really like having > one > > all-in-language-X Apache place to work in. > > > > If you consider the Apache XML project as a comparison, which has a C++, > > Perl and Java version of Xerces for example, I consider that a different > > beast because the concepts of an XML parser translate from one platform to > > another (with possibly [I do not know] similar APIs and object > hierarchies). > > > > > > A lot of the A-J-C is JRE centric. We are talking about extensions to the > > JRE, not just Java components, which do not translate into C or Perl, > since > > those languages have different base libraries. If you think about [lang], > > what aside from the name would be similar b/w a C++, Perl and Java > version? > > The base libraries they would extend have nothing to do with each other... > > > > #2) TLP > > Separate chat ;-) > > > > My 2c, > > Gary > > > > > -----Original Message----- > > > From: Henri Yandell [mailto:[EMAIL PROTECTED] > > > Sent: Wednesday, December 17, 2003 15:00 > > > To: Jakarta Commons Developers List > > > Subject: Commons - TLP > > > > > > > > > [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]
