RE: URI & URIUtil as a separate Commons project?
> Hmm... looks like... most're intersted in some uri encoding methods. (at > least in the mailing list) > However, I will say that URI is generally a parser for some purposes with > having some coder feature. > > As I look into Commons-Codec, well... bula...bula... > And I think it's not a right choice. (I guess, probably they wouldn't think > either) Sung-Gu, What do you mean by "As I look into Commons-Codec, well... bula...bula..."? Undoubtedly, URI specification doesn't belong to Commons-Codec. No one has ever suggested otherwise. The idea is to factor out only URL encoding/decoding logic that clearly does. > > 2) URI specification by itself is just one class. It hardly makes any > sense in my opinion to make a package out of it, even though URI class is > clearly useful beyond HttpClient. > > If you want make an jar, you'd better setup the build.xml when you tar it... This is not just about creating a separate jar file with URI spec implementation. The initial idea was to create Commons-URI sub-project out of existing URI spec implementation in HttpClient. However, as many pointed out, the overhead of maintaining a full fledged Jakarta Commons sub-project around what is essentially one class would be simply too much. This said, if you can write a proposal for Commons-URI sub-project and make a convincing case to the rest of the Jakarta Commons community, we will whole-heartedly support you. Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fw: URI & URIUtil as a separate Commons project?
- Original Message - From: "Sung-Gu" <[EMAIL PROTECTED]> To: "Kalnichevski, Oleg" <[EMAIL PROTECTED]> Sent: Monday, June 23, 2003 11:47 AM Subject: Re: URI & URIUtil as a separate Commons project? > > > > - Original Message - > > From: "Kalnichevski, Oleg" <[EMAIL PROTECTED]> > > Subject: URI & URIUtil as a separate Commons project? > > > > 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 Commons-Codec package. URL > encoding & decoding functions should be merged with Commons-Codec rather > than spun off. HttpClient will introduce Commons-Codec as a dependency in > the future. So, we should rather extend the existing frameworks, not create > competing ones. > > Hmm... looks like... most're intersted in some uri encoding methods. (at > least in the mailing list) > However, I will say that URI is generally a parser for some purposes with > having some coder feature. > > As I look into Commons-Codec, well... bula...bula... > And I think it's not a right choice. (I guess, probably they wouldn't think > either) > > It's just the same case as there are both org.apache.commons.uri and > org.apache.commons.httpclient directories in the commons-httpclient, I > guess. > > > > 2) URI specification by itself is just one class. It hardly makes any > sense in my opinion to make a package out of it, even though URI class is > clearly useful beyond HttpClient. > > If you want make an jar, you'd better setup the build.xml when you tar it... I mean some class files (not only jar) can be exported on the build.apache.org. Sung-Gu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 flexible. Just because it fits right for HTTP URLs doesn't mean it's useful for let's say LDAP URLs. So the URI class might be split into one generic class and special HTTP and LDAP etc. types. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 rather than spun off. HttpClient will introduce Commons-Codec as a dependency in the future. So, we should rather extend the existing frameworks, not create competing ones. Makes sense to me. It would be way too much of an overhead to have a full-blown Commons Subproject for just two classes as well. Just imagine all the building / release process, management, Website etc. And you need developers as well. 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. In terms of reuse, it is quite simple to just pull out the classes and use them separately if required anyway and realistically you don't want to have to add another jar file to your distribution just for URI classes when it's so easy to package them up into your main jar anyway. Just my two cents, Adrian Sutton. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 a dependency in the future. So, we should rather extend the existing frameworks, not create competing ones. Makes sense to me. It would be way too much of an overhead to have a full-blown Commons Subproject for just two classes as well. Just imagine all the building / release process, management, Website etc. And you need developers as well. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 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 a dependency in the future. So, we should rather extend the existing frameworks, not create competing ones. 2) URI specification by itself is just one class. It hardly makes any sense in my opinion to make a package out of it, even though URI class is clearly useful beyond HttpClient. Thoughts, objections, counter-arguments? I agree 100%. Actually I was planning to post the same thoughts in response to the proposal :-) -chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 Commons-Codec package. URL encoding & decoding functions should be merged with Commons-Codec rather than spun off. HttpClient will introduce Commons-Codec as a dependency in the future. So, we should rather extend the existing frameworks, not create competing ones. 2) URI specification by itself is just one class. It hardly makes any sense in my opinion to make a package out of it, even though URI class is clearly useful beyond HttpClient. Thoughts, objections, counter-arguments? Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
