commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <robertburrelldon...@blueyonder.co.uk>
Subject Re: [SURVEY] Commons-URI or not?
Date Thu, 26 Jun 2003 21:14:23 GMT
IMHO the major thing that's needed for this plan to work is a volunteer to 
commit to carry out the necessary leg work. a good place to start would be 
to update (and if necessary fix) the descriptors in commons-combo and then 
add it to gump and the nightly builds.

- robert

On Wednesday, June 25, 2003, at 09:49 PM, Gary Gregory wrote:

> 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:eric@tibco.com]
> 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:
>> 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


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


Mime
View raw message