----- 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]
