Re: [SURVEY] Commons-URI or not? - jarring or ... and exposing some classes?
I'd like to consider the compelete opposite situation. If a project (knows what they exactly need) wanted just several classes from another project, should they include a whole jar from the project? What's the possbile solution? Here you are, my one... You can notice there are xxx.md5, xxx.asc xxx.tar.gz and xxx.zip at http://www.apache.org/dist/jakarta/commons/ How about exposing some classes files at http://www.apache.org/dist/jakarta/commons//classes? Is it nonsense with ant from net? They might be jarred as 'an only jar' in build.xml of antother project Hmmm... Just my simple thought... your opinion please... Sung-Gu - Original Message - From: "Craig R. McClanahan" <[EMAIL PROTECTED]> To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]> Cc: "Commons HttpClient Project" <[EMAIL PROTECTED]> Sent: Thursday, June 26, 2003 2:06 AM Subject: Re: [SURVEY] Commons-URI or not? > > > On Wed, 25 Jun 2003, Eric Johnson wrote: > > > [snip] > > 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: > > > > Have a look at the build.xml file in the "combo" subdirectory of the > jakarta-commons CVS repository -- it lets you do exactly this sort of > thing, and even lets you pick the versions you want (by virtue of > specifying the CVS tags to build with). > > I try to maintain the "latest official release" CVS tag of all released > commons packages (but nothing from the sandbox, since by definition they > are not released), but don't always have a chance to do so in a timely > manner -- others are welcome to help. > > Craig McClanahan > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SURVEY] Commons-URI or not? - with java.net.URI?
> - Original Message - > From: "Shapira, Yoav" <[EMAIL PROTECTED]> > To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]> > Sent: Wednesday, June 25, 2003 9:38 PM > Subject: RE: [SURVEY] Commons-URI or not? > > Howdy, > I think a slightly more detailed proposal is needed: one that addresses > specifically what commons-uri would address that's missing in > java.net.URI and related classes. The main reason required the own URI implementations for Jakarta is portability and extensiblity issue I guess though. Your comment is very reasonable... ;) + Portability: JDK 1.2 or later + Extensibility: - URI-based specific extensiblity for each schemes - New URI related specifications support Comparison with java.net.URI on JDK 1.4 (= one issue of new URI package functionalities) might be important also. The current new URI package has some features (java.net.URI does not...) like: - URI validate parsr (URI character sequence must be escaped, how to prove it?) - Charset-aware URI reference container (possbily lagacy support with old? charset fashion, not UTF-8 though ) - Both escaped & unescaped components manipulations (regarded as only escaped in java.net.URI?) - Escape codec utility (possbile to define correct escaped URI components manually by developers) On top of my head, I can summarize the above much right now. Thank you very much, Sung-Gu > Yoav Shapira > Millennium ChemInformatics > > > >-Original Message- > >From: Sung-Gu [mailto:[EMAIL PROTECTED] > >Sent: Wednesday, June 25, 2003 1:10 AM > >To: Jakarta Commons Developers List; Commons HttpClient Project > >Subject: [SURVEY] Commons-URI or not? > > > > > >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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SURVEY] Commons-URI or not? - about its needs
- Original Message - From: "Eric Johnson" <[EMAIL PROTECTED]> > I too am against a separate URI commons package, at least for the moment. [snip] > 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. I think so... ;) Thank you for clearing the current true issue. Sung-Gu > -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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SURVEY] Commons-URI or not?
The Guidelines of the commons charter has some guidance here: http://jakarta.apache.org/commons/charter.html 1. The primary unit of reuse and release is the package. 2. The package library is not a framework but a collection of components designed to be used independently. 3. Each package must have a clearly defined purpose, scope, and API -- Do one thing well, and keep your contracts. 4. ... HttpClient is generally concerned with URLs but URIs are useful beyond HttpClient. URIs are well documented with relevent RFCs. I think that a seperate RFC conforming URI package would be an excellent addition to Jakarta. A project of this nature should copy the current code from httpclient and start a sandbox project. Development should continue there untill development has been proven and a formal commons project proposal can be made. Likely the developers would want to seek HttpClient as a key user of the new package, but this does not mandate that HttpClient will use the new package. Nor does it require that a jar dependancy be added (re-use can be achieved in multiple ways) but the new codebase could be re-used in other ways if that was deemed preferable. I would support having a seperate URI package. From my perspective the possible benefits are clear and the possible drawbacks are avoidable. Jandalf. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SURVEY] Commons-URI or not? - about starting point
- Original Message - From: "Martin Cooper" <[EMAIL PROTECTED]> To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]> Cc: "Commons HttpClient Project" <[EMAIL PROTECTED]> Sent: Thursday, June 26, 2003 2:37 AM Subject: Re: [SURVEY] Commons-URI or not? > > > On Wed, 25 Jun 2003, 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. > > If you want to do this, I would recommend starting in the sandbox. That > way, we'll find out if it is viable as a standalone component, and, in > particular, if a community develops around it. Yes, I think so. That would be the proper procudure. At this moment, I try to ask others' needs, not simply, rather than their interests and concerns. ;) Thank you, Sung-Gu > Even though the code originates from HttpClient, I would be against a > Commons-URI component starting out in Commons Proper, because history > shows us that a body of code does not always develop into a viable > component, with its own community, just because it comes from an already > successful project. > > -- > Martin Cooper > > > > > > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SURVEY] Commons-URI or not?
On Wed, 25 Jun 2003, Eric Johnson wrote: > [snip] > 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: > Have a look at the build.xml file in the "combo" subdirectory of the jakarta-commons CVS repository -- it lets you do exactly this sort of thing, and even lets you pick the versions you want (by virtue of specifying the CVS tags to build with). I try to maintain the "latest official release" CVS tag of all released commons packages (but nothing from the sandbox, since by definition they are not released), but don't always have a chance to do so in a timely manner -- others are welcome to help. Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SURVEY] Commons-URI or not?
On Wed, 25 Jun 2003, 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. If you want to do this, I would recommend starting in the sandbox. That way, we'll find out if it is viable as a standalone component, and, in particular, if a community develops around it. Even though the code originates from HttpClient, I would be against a Commons-URI component starting out in Commons Proper, because history shows us that a body of code does not always develop into a viable component, with its own community, just because it comes from an already successful project. -- Martin Cooper > > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [SURVEY] Commons-URI or not?
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:[EMAIL PROTECTED] 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? &
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SURVEY] Commons-URI or not?
Chris, This problem is as old as software engineering itself. Code reuse provides many benefits as well as many potential problems such as versioning conflicts. In my opinion benefits still outweigh the problems. Usually code reuse done right results in higher code quality, provided that you get more people looking at it and stressing it in different ways. This is exactly what URI code is in a dire need of. We do plan to introduce other external dependencies in addition to commons-logging, such as commons-codec. This said, we surely will not let the number of external dependencies to get out of hands (Believe me, there are several fine open-source products that I HATE simply because of ridiculous number of dependencies: dom4j, werkflow, drools being one of the most notorious). Any potential external dependency will be subject to thorough analysis and discussion (or even voting) on this mailing list. You can count on that. Cheers Oleg On Wed, 2003-06-25 at 09:27, Chris Brown wrote: > Please NO !!! > > We're now finding it very difficult to use a lot of Jakarta projects, > because of "dependency hell"... it's becoming worse than Microsoft's famous > "DLL hell" problem. The more self-contained you can keep an API, the better > ; yes, there are issues concerning code re-use, but at present, we're having > great difficulty using more than one Jakarta project at a time in our > projects. > > If you only use one Jakarta project at a time, you're generally ok. > > If you try to use more than one Jakarta project at the same time within your > own projects, you have to hope that no such library relies upon any other > commons component, because chances are that they won't be expecting the same > version of each library (they don't always include the latest version of > each "basic" API, and each "main" Jakarta API has a different release > cycle). Commons-logging is generally included as standard. If each version > of an API was always backwards-compatible, maybe that'd work, but that's not > always pratical, realistic, or efficient. > > Or start hacking around with classloaders... and this too becomes a futile > exercise when you start deploying things on some versions of Tomcat (for > example) that "helpfully" expose common functionality, using perhaps > incompatible versions of APIs (usually from commons) that are obsolete (or > more recent than) the versions of these APIs required by some other > "empirical" Jakarta library. > > Some of the recent commons components, such as commons-sql, have a > ridiculous number of dependencies. > > One other observation about Commons projects (and Jakarta/Apache in general) > ; although code re-use seems like a good idea, I'm now seeing several > different projects that aim to do more or less the same thing, such as : > > - ant and maven > - torque and commons-sql > - oro and regexp > - tapestry, turbine, etc. > > Furthermore, if there's Log4J, why not just use it, instead of the > Commons-Logging layer? If a project goes JDK1.4+ -only after, then migrate > to java.util.logging ? > > On a personal note, I'm hoping that commons-net, which used to just work > "as-is", doesn't start depending on lots of different API versions... > > I know this is the HttpClient list, and not some general Jakarta list, but I > sincerely hope that one of the few remaining Jakarta projects that doesn't > depend on many others doesn't go down the same dependency nightmare route as > many of the others, so I wanted to illustrate *why* (as a user) I feel this > way... > > - Chris > > - Original Message - > From: "Sung-Gu" <[EMAIL PROTECTED]> > To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]>; > "Commons HttpClient Project" <[EMAIL PROTECTED]> > Sent: Wednesday, June 25, 2003 7:09 AM > Subject: [SURVEY] Commons-URI or not? > > > > > > 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... > > > > > > > > > > > > > > ---
Re: [SURVEY] Commons-URI or not?
Chris Brown wrote: We're now finding it very difficult to use a lot of Jakarta projects, because of "dependency hell"... it's becoming worse than Microsoft's famous "DLL hell" problem. You can work around the DLL hell by using different class loaders for different Jakarta tools. Odi BTW the DLL hell is not confined to MS operating systems. This is very common on Linux as well. Ever used different versions of the BDB at the same time? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [SURVEY] Commons-URI or not?
As a user of jakarta projects I must say I agree with Chris on this one. No offense, but in the way I see it HttpClient isn't "big enough" to be splitted and to have one more dependency. I met the same trouble as Chris for commons-logging, helpfully most jakarta projects are willing to update to the latest when you ask, but sometimes it takes time. Aurelien Chris Brown a écrit : > Please NO !!! > > We're now finding it very difficult to use a lot of Jakarta projects, > because of "dependency hell"... it's becoming worse than Microsoft's > famous "DLL hell" problem. The more self-contained you can keep an > API, the better ; yes, there are issues concerning code re-use, but > at present, we're having great difficulty using more than one Jakarta > project at a time in our projects. > > If you only use one Jakarta project at a time, you're generally ok. > > If you try to use more than one Jakarta project at the same time > within your own projects, you have to hope that no such library > relies upon any other commons component, because chances are that > they won't be expecting the same version of each library (they don't > always include the latest version of each "basic" API, and each > "main" Jakarta API has a different release cycle). Commons-logging > is generally included as standard. If each version of an API was > always backwards-compatible, maybe that'd work, but that's not always > pratical, realistic, or efficient. > > Or start hacking around with classloaders... and this too becomes a > futile exercise when you start deploying things on some versions of > Tomcat (for example) that "helpfully" expose common functionality, > using perhaps incompatible versions of APIs (usually from commons) > that are obsolete (or more recent than) the versions of these APIs > required by some other "empirical" Jakarta library. > > Some of the recent commons components, such as commons-sql, have a > ridiculous number of dependencies. > > One other observation about Commons projects (and > Jakarta/Apache in general) > ; although code re-use seems like a good idea, I'm now seeing several > different projects that aim to do more or less the same thing, such > as : > > - ant and maven > - torque and commons-sql > - oro and regexp > - tapestry, turbine, etc. > > Furthermore, if there's Log4J, why not just use it, instead of the > Commons-Logging layer? If a project goes JDK1.4+ -only after, then > migrate to java.util.logging ? > > On a personal note, I'm hoping that commons-net, which used to just > work "as-is", doesn't start depending on lots of different API > versions... > > I know this is the HttpClient list, and not some general Jakarta > list, but I sincerely hope that one of the few remaining Jakarta > projects that doesn't depend on many others doesn't go down the same > dependency nightmare route as many of the others, so I wanted to > illustrate *why* (as a user) I feel this way... > > - Chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SURVEY] Commons-URI or not?
Please NO !!! We're now finding it very difficult to use a lot of Jakarta projects, because of "dependency hell"... it's becoming worse than Microsoft's famous "DLL hell" problem. The more self-contained you can keep an API, the better ; yes, there are issues concerning code re-use, but at present, we're having great difficulty using more than one Jakarta project at a time in our projects. If you only use one Jakarta project at a time, you're generally ok. If you try to use more than one Jakarta project at the same time within your own projects, you have to hope that no such library relies upon any other commons component, because chances are that they won't be expecting the same version of each library (they don't always include the latest version of each "basic" API, and each "main" Jakarta API has a different release cycle). Commons-logging is generally included as standard. If each version of an API was always backwards-compatible, maybe that'd work, but that's not always pratical, realistic, or efficient. Or start hacking around with classloaders... and this too becomes a futile exercise when you start deploying things on some versions of Tomcat (for example) that "helpfully" expose common functionality, using perhaps incompatible versions of APIs (usually from commons) that are obsolete (or more recent than) the versions of these APIs required by some other "empirical" Jakarta library. Some of the recent commons components, such as commons-sql, have a ridiculous number of dependencies. One other observation about Commons projects (and Jakarta/Apache in general) ; although code re-use seems like a good idea, I'm now seeing several different projects that aim to do more or less the same thing, such as : - ant and maven - torque and commons-sql - oro and regexp - tapestry, turbine, etc. Furthermore, if there's Log4J, why not just use it, instead of the Commons-Logging layer? If a project goes JDK1.4+ -only after, then migrate to java.util.logging ? On a personal note, I'm hoping that commons-net, which used to just work "as-is", doesn't start depending on lots of different API versions... I know this is the HttpClient list, and not some general Jakarta list, but I sincerely hope that one of the few remaining Jakarta projects that doesn't depend on many others doesn't go down the same dependency nightmare route as many of the others, so I wanted to illustrate *why* (as a user) I feel this way... - Chris - Original Message - From: "Sung-Gu" <[EMAIL PROTECTED]> To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]>; "Commons HttpClient Project" <[EMAIL PROTECTED]> Sent: Wednesday, June 25, 2003 7:09 AM Subject: [SURVEY] Commons-URI or not? > > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
