Re: URI & URIUtil as a separate Commons project?

Adrian Sutton wrote: Sounds quite reasonable. The other thing to consider is exactly how much the URI classes are likely to change anyway. They pretty much do what's required now and I find it hard to imagine there'd be too many changes that need to be made. Code can always be nicer and more f

Re: HttpClient Testimonials

OK, I'll bite. My temptation was to provide a bullet point list, but since you requested _paragraphs_, that means I have to have fully formed thoughts! We've used HttpClient in a variety of projects throughout my company. Someone I work with had an interest in the project, so we tried it out

Re: URI & URIUtil as a separate Commons project?

On Tuesday, June 17, 2003, at 10:49 PM, Ortwin Glück wrote: Kalnichevski, Oleg wrote: 1) URL encoding logic that constitutes almost a half of the reusable code in URI related classes clearly belongs to Commons-Codec package. URL encoding & decoding functions should be merged with Commons-Codec ra

Re: URI & URIUtil as a separate Commons project?

Kalnichevski, Oleg wrote: 1) URL encoding logic that constitutes almost a half of the reusable code in URI related classes clearly belongs to Commons-Codec package. URL encoding & decoding functions should be merged with Commons-Codec rather than spun off. HttpClient will introduce Commons-Codec as

Re: URI & URIUtil as a separate Commons project?

Kalnichevski, Oleg wrote: Sung-Gu and all, I must confess I have had a change of heart on this issue. I am no more convinced that URI & URIUtil classes should be spun off into a Commons project of its own. 1) URL encoding logic that constitutes almost a half of the reusable code in URI related cl

URI & URIUtil as a separate Commons project?

Sung-Gu and all, I must confess I have had a change of heart on this issue. I am no more convinced that URI & URIUtil classes should be spun off into a Commons project of its own. 1) URL encoding logic that constitutes almost a half of the reusable code in URI related classes clearly belongs to

DO NOT REPLY [Bug 10816] - User/Developer Documentation

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

HttpClient Testimonials

Hi all, One of the last bits of documentation to be added to the HttpClient site (for now at least) is a section on why people chose to use HttpClient over the alternatives. If you could take the time to put together a paragraph or two describing the key benefits of HttpClient that made you ch

DO NOT REPLY [Bug 10816] - User/Developer Documentation

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

RE: DO NOT REPLY [Bug 10809] - Developer documentation

Adrian, I would even go as far as closing this one too: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10816 In my opinion HttpClient documentation is now feature complete. We may still need to work on improvement of individual documents, but in broad strokes I think we are done. Is there a

DO NOT REPLY [Bug 10809] - Developer documentation

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 20826] - HttpMethod#getResponseBody throws NPE

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu