Re: Avoid building against Head of Commons Httpclient
Ingo, this will not work. You will need to add a work nested=lib/commons-httpclient.jar/ or something similar. Gump only uses the system classpath, so any classpath additions defined in the Ant file are ignored. It would be nice if there was a separate project for the 2.0 branch of Commons-HttpClient, given that the community has decided to follow the path of revolutionary change. [EMAIL PROTECTED] should provide answers to any questions (philosophical as well as technical ;-) ). -chris PS: Why is slide now keeping all those JARs in CVS? It is a practice that wasn't followed before, only for rare circumstances when e.g. JDOM broke their API in HEAD (similar to the current situation with HttpClient). Personally, I consider it bad practice, but I'm no longer actively involved with Slide, so... Ingo Brunberg wrote: Hi, I have modified Gump's project definition for Slide, so that it (hopefully) builds against the included commons-httpclient.jar. This should give us working nightly builds again. Regards, Ingo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Add commons-codec as an HttpClient dependency
Kalnichevski, Oleg wrote: True, but neither has HttpClient 2.1:) We will most likely have to put some effort into getting a final codec release that contains this code. I agree, adding a jar could be considered an API break, but it was part of our plan for 2.1. The only real API changes that this requires is removing the already deprecated Base64 code. The EncodingUtil class will not be changed. Right, but the problem is those folks who use CVS snapshots while insisting on complete (maximum) API compatibility with 2.0 branch. They have not been quite receptive to 'but it was part of our plan for 2.1' kind of arguments up to now. Chill out, dude. Personally, I was not insisting on complete (maximum) API compatibility, but was just offended/scared by your tone. I didn't expect to hear we guarantee 100% backwards compatibility, just a we'll try to preserve backwards compatibility as much as possible. I have read the 2.1 release plan when it was posted, and if I (as a user) would not have been in agreement, I'd have voiced my concerns. I also think that migrating to Commons-Codec is a good idea, and it should be a very managable change for all API clients (for example, there's no problem adding Commons-Codec to the classpath of HttpClient 2.0.x). Of course, I can put up the same 'Evil Comrade' act as always, but I have a feeling that some of them did not quite appreciate my sarcasm. You could also work on choosing your words more carefully sometimes, put a little smiley behind sarcastic statements, and fix your caps lock ;-) -chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvscommit: jakarta-commons/httpclient/src/test/org/apache/commons/httpclientTestAuthenticator.javaTestHttpState.javaTestHttps.javaTestMethodsExternalHost.javaTestWebappBasicAuth.java
Hi Oleg, this thread has gotten a bit out of hand now... I personally trust the HttpClient team to make the right decisions about the future of the code, and I even agree with the wording of the 2.1 release plan. Breaking 2.0 API compatibility where absolutely unavoidable is acceptable, as long as that sentence cannot interpreted as a free ticket to change the API all over the place. Now, what started this discussion was just me pointing out that you removed a technically non-deprecated method. Your response sounded a bit offensive, implying that we're doing something weird by using CVS HEAD of HttpClient (which is totally normal at Jakarta). And your comment about API compatibility sounded like you don't care very much about preserving compatibility. There is a *huge* difference between we should make all possible efforts to keep API compatibility (Michael) and we will no longer be able to provide API compatibility (Oleg). And the difference might not even be technical ;-) Cheers, -chris -- Christopher Lenz /=/ cmlenz at gmx.de - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Test Coverage
Adrian Sutton wrote: Howdy all, We now have a license for clover to analyze our test cases and am now just starting to work through adding test cases to improve our code coverage. I've very quickly come to the realization that 100% code coverage may actually be a bad thing. I've gotten AuthChallengeParser to 100% coverage now so let me use it as an example: There are four test cases that I consider pedantic and 1 of those that I really don't like. The pedantic ones are: * test that AuthChallengeParser.extractScheme(null) throws an illegal argument exception instead of a null pointer exception. What difference does this really make? The only reason I can think of to keep the test is so that the implied interface for the method is kept the same (it never throws a NPE but throws an illegal argument exception instead). * Test that AuthChallengeParser.extractParams(null) throws an illegal argument exception not a NPE. Same as above really. * testParamsWithNoName(). Check that AuthChallengeParser.extractParams(Basic realm=\test\,=\invalid\); throws a MalformedChallengeException because there is no name part to the name/value pair. This is good if we're in strict mode but if not wouldn't it be better to be lenient and just ignore that param (with a logged warning)? I wouldn't call these tests pedantic. They verify the contract of the class. The contract is either defined explicitly by being documented, or implicitly defined by the current behaviour, which someone may depend on (some other class inside HttpClient, or an external API client). The one I really don't like is: * Test that AuthChallengeParser.extractScheme( Basic realm=\realm\); throws a MalformedChallengeException because there's a leading space. Now in strict mode that's fine and within HttpClient the leading space is stripped before being passed in but it seems overly strict to me. Again, if the contract of that method says that a leading white space -- or some other irregularity -- causes a specific exception to be thrown, it is good that there are test cases to verify the contract. Maybe it is not the test that you dislike, but rather the behaviour of the method? In that case the contract should be changed to say any leading or trailing white space will be trimmed or something like that. But that has nothing to do with the test being invalid IMHO. Now, I don't mind what happens with any of these decisions to be honest as none affect the actual behaviour of HttpClient - they are very much edge cases. I would however like to set up a policy on the types of test cases I should create (do we want to avoid testing things like the pedantic things above) as well as the best way to keep track of questionable or overly pedantic test cases. Currently I'm just adding a // pedantic above any test case that seems pedantic and a todo comment over anything that I think may require a change to the code but isn't clearly a bug. I figure from time to time I can provide a list of issues that need to be considered as I work my way through the codebase. Personally, I'm hoping to achieve 100% test coverage firstly because I've discovered how dependent I am on having good test cases while working on HttpClient (most people don't have the detailed level of knowledge that Mike and Oleg do and thus aren't aware that a change will break some other section of code - NTLM is a regular victim of this). Also, aiming for 100% coverage makes a very clear-cut decision on when the job is done which make life easier as well and makes it much more noticeable when new test cases need to be added. Any thoughts? Achieving 100% (or any other hard number) of code coverage is a lot of work, and almost never guarantees that the code is free of errors. Making some percentage of code coverage a hard requirement is usually missing the point. Of course, more coverage is usually good, but there's a point of diminishing return Anyway, while tests like the pedantic ones you outlined are probably not critical, I see no reason to throw them away if they're already present. They serve the very good purpose of testing error conditions and asserting the contract of the class under test. Just my two cents. -chris - 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]
Re: call for projects using httpclient
Jeffrey Dever wrote: If you have an application that uses HttpClient, and would like to see it on our applications page, please send an email to: [EMAIL PROTECTED] http://jakarta.apache.org/commons/httpclient/applications.html Jakarta Cactus (http://jakarta.apache.org/cactus/) A framework for unit testing server-side java code. -- Christopher Lenz /=/ cmlenz at gmx.de -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Digester] Re: DO NOT REPLY [Bug 12756] - [Patch] CallMethodRule/CallParamRule
Hi John, I'd also like to see the functionality you describe in Digester. I needed to do equivalent changes in my local workspace to meet the requirements of my use cases, but my personal patch queue against Digester is still not cleared so ... :-P Just to add a bit of pressure behind this issue ;-P John Yu wrote: I haven't got any response/comment on this patch I submitted a week ago. Some feedback please. :-) At 09:56 am 25-09-2002, you wrote: DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12756. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12756 [Patch] CallMethodRule/CallParamRule [EMAIL PROTECTED] changed: What|Removed |Added Summary|[Patch] |[Patch] |CallMethodRule/CallParamRule|CallMethodRule/CallParamRule --- Additional Comments From [EMAIL PROTECTED] 2002-09-25 01:55 --- It seems the fix from Bug#11693 has addressed (partly?) the last issue that CallMethodRule didn't work correctly in nested situation. -- Christopher Lenz /=/ cmlenz at gmx.de -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Digester] XML Pull
The architecture of Digester is very close to the SAX push parse model. SAX events are simply dispatched to matching rules. Using a lower-level API like XMLPULL would just complicate the code, because Digester would have to translate between the pull and the push model. Not to speak about API compatibility ;-) BTW, I *highly* doubt that the SAX parsing is a performance bottleneck in Digester. I assume that performance is most affected by the relection/introspection routines that are used to create objects, set properties, call methods, etc. Tal Lev-Ami wrote: Performance. Parsers like XPP are much faster than any available SAX parser (at least that I know of). See http://www-106.ibm.com/developerworks/xml/library/x-injava. The performance comes at the expense of full standard compliance but for most documents that isn't really important. I don't think that XML Pull should replace SAX, just be another usage option. I haven't done a benchmark of the Digester it self, maybe the XML parsing part is not the main problem, but I have a feeling it is. Tal Lev-Ami Trivnet Ltd. -Original Message- From: Scott Sanders [mailto:[EMAIL PROTECTED]] Sent: Wed, September 18, 2002 1:27 AM To: Jakarta Commons Developers List Subject: RE: [Digester] XML Pull Would there be a good reason for it, other than because we can? Scott -Original Message- From: Tal Lev-Ami [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 17, 2002 5:13 AM To: Jakarta Commons Developers List (E-mail) Subject: [Digester] XML Pull Anybody tried to adapt the Digester to work with XML Pull (http://www.xmlpull.org)? It should be fairly easy to do and there are pretty fast parsers out there. Tal Lev-Ami Trivnet Ltd. -- Christopher Lenz /=/ cmlenz at gmx.de -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Proposal] Scamp: Source Control Abstraction
Hi Lance, I think this JSR is quite related to your proposal: http://www.webdav.org/deltav/wvcm/ Albeit inspired by WebDAV/DeltaV, I believe it is supposed to be generic. Also, AFAIK, it is initiated by an Eclipse team member, so its implementation is heading open-source. Weber, Lance wrote: Following some interesting discussions on the Maven list, I'd like to propose starting an SCM abstraction project, tentatively named Scamp. Proposed Goal: Scamp is a Source Control Manager abstraction layer. It provides a standard interface to SCM systems allowing common source control operations such as checkin/checkout, labelling/tagging, reading changelogs and diffs. Initial design goals: -- expose a stable SCM interface contract for consuming applications (Maven, Ant, etc). -- provide extensible infrastructure for specific SCM implementations. -- configuration driven implementations -- file system independent -- supports multiple projects, multiple/distributed source providers Architecture: My initial thoughts are to utilize a combination of AbstractSCMFactory and a SourceControlManager interface with concrete implementations of both. We might possible need some secondary classes representing projects, connections, and filesystems, but I'm not sure on those yet. 0.1 Release Goals/Requirements: -- First version of SCM Interface, focused on primary/core SCM operations -- AbstractSCMFactory -- Stubbed concrete factories for cvs/vss/vfs? -- exception infrastructure Any thoughts, feedback, requirements, design, existing code pointers, etc very welcome. Potential participants more than welcome!! Thanks, Lance -- Christopher Lenz /=/ cmlenz at gmx.de -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
