commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <>
Subject RE: [SURVEY] Commons-URI or not?
Date Wed, 25 Jun 2003 20:49:04 GMT
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?


-----Original Message-----
From: Eric Johnson [] 
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
>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?
>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: 
>For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message