I like this idea. I would also propose: o This "commons.jar", "commons-all.jar" or whatever it should be called be part of the nightly-build. If a sub-component's build failed, then this build fails. o A release of commons-all would be automatically attempted when a new release of a sub-component is successful. o This project would not contain code but additional unit tests perhaps to insure that all the pieces play together nicely. Tricky stuff perhaps.
Having one jar does not solve the issue we currently have where code is duplicated b/w for example collections and lang because neither project wants to depend on the other. Worse, I am sure useful features are not being used to avoid dependenices. If you were to look at commons in one jar and see this duplication it would be, well... That's the way it is. Perhaps we should have a commons-core project/jar that all other projects can depend on instead of duplicating code. The criteria for putting something in core, which BTW, could just have the "proper" package name for its classes and not a "core" package name, would be simple: if two projects duplicate code, put it in core. I am not sure how messy and hairy this would be, but it certainly could be. Aside from allowing dependencies and creating a commons dependency tree when projects use each others features, what else can we do? Gary -----Original Message----- From: Eric Johnson [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 25, 2003 06:39 To: Commons HttpClient Project Cc: Jakarta Commons Developers List Subject: Re: [SURVEY] Commons-URI or not? It would seem that most if not all of the responses from the HttpClient crew responded only to the HttpClient list, and not to commons dev. So I'm not sure that all that might need/want to see the entirely negative feedback have seen it. I don't subscribe to commons-dev, so if this doesn't get through, would someone mind reposting it there? I too am against a separate URI commons package, at least for the moment. In any event, who else depends on a URI class? At the moment, there are three obvious sources for URI type functionality that I am aware of: HttpClient, Slide, and JRE 1.4. Slide, rather than using what is in HttpClient, is using its own, even though Slide includes HttpClient in its build dependencies. Without anyone even sharing the code in the first place, it doesn't seem like a good candidate for a separate project. One of the negatives that others have mentioned on the HttpClient list is the growing dependency problem within the Apache projects, particularly with the myriad of dependencies on commons projects, and among the commons projects themselves. Perhaps what we need to do is start clumping some of the commons projects together, as well as having the stand-alone pieces we have now. A first cut at combining some of the commons projects into one giant JAR might include: * beanutil * cli * codec * collections * dbcp * fileupload * httpclient * lang * logging * net * pool My criteria for the above list were three-fold - base requirement of JRE 1.2 or later, that the project should have an official blessed release, and that it shouldn't depend on any outside libraries - like an XML parser - at runtime. And I'll admit that I'm fudging on HttpClient (and file upload) a little, in that I don't think anyone following HttpClient would want to include the 1.0 release, but I'm guessing that by the time such a project is agreed upon and pulled together, HttpClient 2.0 will be final.... At least here's to hoping. Anyway, to the extent that a separate URI package would make sense, if we had a model such as the above, where most people used the one giant JAR instead of the individual ones, the creation of a separate commons URI project would be largely one of focus and interest, rather than an additional dependency quagmire. -Eric Johnson Sung-Gu wrote: >Hi all, > >I suggest that jakarta-commons provides flexible URI issue >implementations as a package. > >Various applications using URI concept comes in the internet world. and >they need common mechanisms and algorithms for URI. > >For example, all internet programs will need fundamental functionalites >of URI like extensible parsing and manipulation container for URL >reference, URN and URC, escape codec mechanism, charset tranformation >functionality, URI transformation from real world identities or URN, or other >transformations related to DNS or telephony... If it would be prepared >commonly in Jakarta, we can save development powers. So I suggest new >commons-uri package. > >FYI, currently the commons-httpclient is using it. > >Any comments? >Or any +1, -1? > >Sung-Gu > >P.S.: If the requirement is very weak, I want to put the new package >into commons-sandbox even for a long while in my opinion... > > > > >----------------------------------------------------------------------- >- > >--------------------------------------------------------------------- >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]
