Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Message-ID: <3EF9A5E4.7040802@tibco.com>
Date: Wed, 25 Jun 2003 09:38:44 -0400
From: "Eric Johnson" <eric@tibco.com>
Organization: TIBCO Extensibility
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.3) Gecko/20030312
MIME-Version: 1.0
To: Commons HttpClient Project <commons-httpclient-dev@jakarta.apache.org>
CC: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: Re: [SURVEY] Commons-URI or not?
References: <BAY1-DAV12O8FNpyLAP00027dd8@hotmail.com>
In-Reply-To: <BAY1-DAV12O8FNpyLAP00027dd8@hotmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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: commons-httpclient-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org