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]
