We should be able to do a build without having to much of Jeff's time.
I think we are capable of doing most of the steps except for maybe the
deploy. Jeff, what do you think?
I documented the release process the best I could for just such
emergencies. But since I am not currently in Iraq,
Good point. Looks like a reasonable fix.
Michael Becke wrote:
It seems that it's the HTTP/1.1 request. Wget uses 1.0. If I call
HttpMethodBase.setHttp11(false) all works well.
Mike
On Thursday, March 27, 2003, at 11:30 PM, Jeffrey Dever wrote:
Thats strange. When I hit it with wget
Thats strange. When I hit it with wget --debug I get a reasonably
formed response:
HTTP/1.0 200 Document follows
Date: Fri, 28 Mar 2003 04:25:19 GMT
Server: NCSA/1.5.2
Last-modified: Sun, 25 Nov 2001 08:40:58 GMT
Content-type: text/html
Content-length: 4732
Strange that they used Document
I'd say that a post redirect converted to a get is good behaviour to add
as part of the redirect overhaul as discussed for httpclient 3.0
Tom Samplonius wrote:
On Mon, 17 Mar 2003, Matthew S. Ring wrote:
...
conflicts with RFC 2616. Is this stringency really neccesary? Selfishly, it
The patch adds getResponseContentLength to HttpMethodBase, which is
good, but it should also go into the HttpMethod interface. I think that
this is a safe change at this point.
[EMAIL PROTECTED] wrote:
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB
go4it
Michael Becke wrote:
Are there any comment for or against the following patches?
the patch attached to:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17563
and:
Begin forwarded message:
From: Michael Becke [EMAIL PROTECTED]
Date: Sat Mar 1, 2003 12:36:02 PM US/Eastern
To:
We really have 3 different type of tests:
nohost: those that run entirely within the test JVM
remote: those that hit some number public internet resources
webapp: those that require the httpclient .war deployed in a container
There is nothing special about the host that the webapp resides. A
There is no user list, everyone just works off of the dev list.
HttpClient is not an application, its a HTTP client site framework in
Java. Its by developers, for developers and such there is little need
for a user list at this time.
All HttpClient questions and discussion are best done here.
- certainly would prefer Wire, WireLogInputStream, WireLogOutputStream
to be package access, not public
So do I. I just find it illogical that HttpMethodBase and all classes
derived from it reside in different packages. That causes the problem in
the first place. Visibility of Wire,
Done. Looks like a cool project!
http://jakarta.apache.org/commons/httpclient/applications.html
Max Voelkel wrote:
Hi middle earth,
yet another project using Jakarta Commons HttpClient.
It's the result of my (yet unfinished) diploma thesis.
I apologize for my bad english. When i made a mistake,
I think its justified too. The copywrite date in any new files should
just be 2003. Odi's name might have been munged again. Other than
that, its cool. Might need come updates to the xdocs/logging.xml
logging guide?
Oleg Kalnichevski wrote:
Jandalf
I have tried to incorporate your
: HttpClient IRC event - date set
Damn, I will be at the climbing wall at that time
Jeffrey Dever wrote:
The inagural HttpClient IRC even will be held tomorrow:
Date: 20:00-22:00 UTC Thursday Feb 27
Server: irc.freenode.net
Channel: #httpclient
Tenative Agenda:
- Middle Earth nicks
The preliminary window looks like 20:00-22:00 GMT Thursday Feb 26. I
hope that everyone can make it in this window.
Still looking for a IRC server and a channel. Any IRC gurus interested
in dealing with this?
Jandalf wrote:
I think its about time for an IRC session. There is lots to talk
the outstanding issues
to developers. There should be clarity regarding who tackles what issue.
What do you think?
Oleg
On Tue, 2003-02-25 at 21:39, Jeffrey Dever wrote:
We are now back in the Beta 1 development phase. There are currently 14
outstanding issues to tackle before we can drop another
Jandalf
Martin Cooper wrote:
-Original Message-
From: Jeffrey Dever [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 26, 2003 7:27 AM
To: Commons HttpClient Project
Subject: Re: HttpClient IRC event - preliminary window
The preliminary window looks like 20:00-22:00 GMT Thursday Feb 26
Looks good here.
[EMAIL PROTECTED] 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=16419.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Oleg
On Mon, 2003-02-24 at 14:02, Oleg Kalnichevski wrote:
I hope it works this time around
Oleg
On Thu, 2003-02-13 at 07:30, Jeffrey Dever wrote:
Haven't had time to review all of this, but I am a bit concerned over
any performance issues and buffering. The wirelog is a good thing
This is an intermediate alpha release. The build process used in the
previous Alpha 2 changed from generating 4 build artifacts to a single
distribution. This one zip contains everything: all the source, the
binary jar, the logging dependancy, generated javadoc and required build
files for Ant
Hopefully the last release candidate for alpha3, rc4, is ready:
http://jakarta.apache.org/builds/jakarta-commons/release/commons-httpclient/v2.0
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
+1
Jeffrey Dever wrote:
Propose to promote the current 2.0 Alpha 3 release candidate 4 to the
offical release of 2.0 Alpha 3. The next release will be 2.0 Beta 1
which will commence after all Beta 1 targeted bugs are closed.
+1 yes
+/- 0 abstain
-1 no
http://jakarta.apache.org/site
We are now back in the Beta 1 development phase. There are currently 14
outstanding issues to tackle before we can drop another release. Work is
going extremely well. Great thanks to everyone that was involved!
We should be addressing the beta 1 bugs before other issues. I think
that we can
No. Its still preliminary.
Jesus M. Salvo Jr. wrote:
Did Oleg's work on the redirect made it to alpha3 rc4?
Oleg Kalnichevski wrote:
Folks
I was going to start working on it today. If there are any other takers,
please let me know
Cheers
Oleg
On Mon, 2003-02-24 at 07:27, Jeffrey Dever wrote
To implement this feature (full redirects), there are really only three
general choices that make sense:
1) augment HttpMethodBase.execute()
Pros: current functionality is maintained
Cons: makes complex code more complex,
2) have two stage redirection done partially in HttpMethodBase and part
This is an intermediate alpha release. The build process used in the
previous Alpha 2 changed from generating 4 build artifacts to a single
distribution. This one zip contains everything: all the source, the
binary jar, the logging dependancy, generated javadoc and required build
files for Ant
Ok, new rc2 package available:
http://jakarta.apache.org/builds/jakarta-commons/release/commons-httpclient/v2.0
Michael Becke wrote:
If we are only going to release one file I would suggest using zip
instead of tar.gz.
Mike
On Monday, February 24, 2003, at 02:10 AM, Jeffrey Dever wrote:
I
() is a killer for the
MultiThreadedHttpConnectionManager. It releases all connections
before they are used in a method. I should have complained more
loudly about this one before you put the effort into tagging CVS.
Sorry.
Mike
On Monday, February 24, 2003, at 09:43 PM, Jeffrey Dever wrote
This is currently on the todo list. Refer to the following bug for more
information:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16729
Adrian Sutton wrote:
So I am wondering ... in the case of a different host and port ( and
protocol? ), why not also call setHostConfiguration() ... and
I just put up a release candidate for alpha3:
http://jakarta.apache.org/builds/jakarta-commons/release/commons-httpclient/v2.0
It was build with the ant task instead of maven this time. I made a few
tiny changes that have not been checked in to cvs yet, and repository
has not been labeled. If
This is a good idea, particularly for updating a JProgressBar. Can you
please bring this up on the [EMAIL PROTECTED]
mailing list?
Thoralf Rickert wrote:
Hi!
I'm not subribed to the list, so please make a CC to my address...
I'm working on a small WebDAV application based on the
Thoralf Rickert wrote:
Hi!
I'm not subribed to the list, so please make a CC to my address...
I'm working on a small WebDAV application based on the
org.apache.webdav library. For user feedback it is necessary to know
how many bytes a Put request has already finished
Mike has passed the vote and should receive commit access to the cvs
repository soon. Welcome aboard Mike!
http://jakarta.apache.org/commons/httpclient/news.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
- a Cache (mentioned a while ago on the list)
A possibility, but likely more re-usable as a seperate project (there is
currently the beginnings of a cache in the sandbox, but appears idle)
- Proxy-Detection
Another possibility
- Some kind of User-Agent on top of HttpClient which:
Mike Becke has been an active contributor for many months. He has
worked on a diverse range of problems with high quality results. He has
been consistant, reliable, helpful and open to ideas and criticism.
There are many excellent contributors to HttpClient, but at this time I
would like to
In general, I support anyone that wants to vote. Due to the structure
of Apache and Jakarta, only committer votes are binding so only these
votes are reported to the PMC and recorded.
If we get to a point where the committers disagree with the community as
a whole, then I want to know about
There are some changes coming down the pipe for the structure of
Jakarta. I have not been involved in these types of discussions untill
now, and am still grappling with what is going on. The most immeadiate
issue is who is going to make up the PMC. The idea seems to be that all
committers
Patch committed.
Aurelien Pernoud wrote:
10 users using 5 requests (no cache implemented for this test), I have some
recoverable exception, but no errors at all !
Nice work ;)
I'll try it later on a real server with more users cause here I was limited
with total connections allowed by my
In a very large project I am a senior on, I use to be using HTTPClient v0.3-3
(www.innovation.ch/java/HTTPClient/).
b) After looking at the code to try to fix the problem, not only did I give up
trying to fix the problem, but I also gave up on the product :)
Yes, I went through exactly the
I was looking for just one physical location to manually put release
packages, with any mirroring/grouping/multiple locations to be done
automagicly. Not wanting to break anything or remove old links, just
wanting efficient use of computer resources and simple processes to follow.
Jeff.
Not sure about that chunk error, but HttpClient does not allow
forwards across hosts. The webpage you posted is using a form based
login. You should probablly look at the html source and figure out how
to do what the browser is doing, as opposed to what the user is doing.
(read that twice)
There appears to be (at least two) locations for releases that need to
be manually updated: one on jakarta.apache.org and one on
www.apache.org. Are we supposted to keep both of these manually
updated? Why are there two? I have an account on deadalus, but where
would I even go to modify
updating that needs to be done since it's just a case of dropping the
release off in two places.
- robert
On Thursday, February 13, 2003, at 08:14 PM, Jeffrey Dever wrote:
There appears to be (at least two) locations for releases that need
to be manually updated: one on jakarta.apache.org and one
Good argument. I'd say you are right that cookies should be
accepted/rejected based on individual merits and not on the entire
cookie header. A patch (in unidiff format) would be helpful in
evaluation what you propose to change.
Jandalf.
Couball, James wrote:
Hello All,
I have a problem
Haven't had time to review all of this, but I am a bit concerned over
any performance issues and buffering. The wirelog is a good thing, but
there are other ways of getting a request/response log. I wouldnot like
to see it excessively effect performance or resident set size, or add
too much
I'd like to propose an alpha3 build. We were going to go right to beta,
but I'd like to do another alpha even if its just for working out the
bugs in the release process. I wrote a release procedure last time, but
it is still needing some attention before its right. Also, the alpha2
build
Sounds a bit casual, but reasonable.
+0
Martin Cooper wrote:
On Sat, 8 Feb 2003, Jeffrey Dever wrote:
Just curious, if this is the first release build ever, should it not be
labeled Alpha1?
FileUpload has been in use by external customers such as Struts and
Turbine for some time now
My thought was that people creating specific instances of HttpMethod
like PostMethod would be able to access the HeaderGroups. I still
would like to have the header groups available for subclasses though.
How would you feel about making these methods protected?
Protected would be fine.
I
, ...).
Thank you a lot for this great package!
Luc Claes
RD Manager, ContactOffice Group SA.
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
Just curious, if this is the first release build ever, should it not be
labeled Alpha1?
Martin Cooper wrote:
Here's my own +1.
--
Martin Cooper
On Sat, 8 Feb 2003, Martin Cooper wrote:
The FileUpload component has been stable for a while now, but available
only from nightly builds. It's
2068 has been replaced by 2616, so I'll use that as the basis for this
discussion.
To determine if this is compliant behaviour, there are a couple of
questions to answer.
1) Does a empty body qualify as a chunked body?
Chunked-Body = *chunk
last-chunk
they should
Cheers
Oleg (Olegolas)
On Fri, 2003-02-07 at 23:16, Jeffrey Dever wrote:
Agreed. If we were building an application, then we could arbitrairly
decide to use whichever jre version that was most suitable. But we are
not building an application, we are building a framework. As a result
Hi Mike,
I'm concerned about having public methods in HttpMethodBase that
are not in the HttpMethod interface. These two public interfaces should
not diverge. I had this same problem in the past, where I added a
public method to the abstract class, and not the interface. Then I saw
user code
I guess no comments are good comments ;-)
I'll check in the patch.
Jeffrey Dever wrote:
I was too hot on the send button. This'll help ;-)
I have tests that I'm just committing now ...
Adrian Sutton wrote:
Jeff,
There was no attached patch. :) At least, not at my end
Thanks
I've been thinking about it too. I still feel that we should keep the
HeaderGroup behind the scenes, and only expose Header[]. This will
still solve the requirements of this feature, while protecting users
from change.
We can consider making HeaderGroup public in 2.1.
Ideally we could add
The Commons Codec project (currently in the sandbox) is taking the
responsibility for maintaining the Base64 class that is in common use in
Jakarta.
They initially took the code from the httpclient package (including the
associated tests), and have merged some changes that were made by the
I created some tests for this issue and checked them in.
Attached is a patch to fix the issue and make the tests pass, but it
needs to be reviewed. I changed slightly the semantics of one very
important method: HttpConnection.readLine().
It now requires the a \r\n be present as a pair to
Engineer
Ephox Corporation
www.ephox.com
-Original Message-
From: Jeffrey Dever [mailto:[EMAIL PROTECTED]]
Sent: Friday, 7 February 2003 2:33 PM
To: Commons HttpClient Project
Subject: [patch] for Bug 16864
I created some tests for this issue and checked them in.
Attached is a patch
Looks like a reasonable comparison. NTLM auth is listed as soon, but in
fact it is available now.
Plug Compatable (ie have a HttpUrlConnection interface). We do have
one that was contirbuted by Vincent Massol from the Jakarta Cactus
project. Its only partially implemented, but nobody has
is the transmission byte order defined for the
type. Lastly, HTTP allows transmission of text types with any of several
line break conventions and not just the canonical form using CRLF.
Tim O'Brien
-Original Message-
From: Jeffrey Dever [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February
Fair enough. I guess the normal case would be just
encode/decode(byte[]) without 76 character chunks, which is what
HttpClient would be using anyway.
So I take back any preference to method signature, except that the
normal or default case be not chunked. If xml-rpc is going to be
using
That sounds good here too. We only call Base64 methods a couple of
times anyway, so adaptation is a minor issue.
Just a note about tests, we have a Junit test class (not sure if xml-rpc
has one) that should go along with the main Base64 class. You did a
grep on the code base so I'm sure you
Base64 is well understood just as a general encoding scheme outside of RFC
2045 MIME. RFC 2045 MIME adds a further requirement that the content be
put into 76 character chunks. Past 1.1 we could also talk about Base64.java
providing the core base64 encoding, and MIMEBase64.java extending
Well said. Totally agree.
Ryan Hoegg wrote:
We do as well. Codec should probably end up with the union, not the
intersection However, ours tests for the MIME specific 76 character
line wrapping.
--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net
Jeffrey Dever wrote:
That sounds
There were a couple threads over on the commons-dev list about having a
seperate VOTE list for all commons issues. I was in support of this,
but was clearly in the minority. The issue is now closed: all voting
will take place on the list where the issues are discussed.
Therefore, votes
://issues.apache.org/bugzilla/show_bug.cgi?id=16440
So, I'll make a proposal and hope for lazy consensus:
Let's replace Base64 in codec with the current HttpClient version.
Tim O'Brien
-Original Message-
From: Jeffrey Dever [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 03
The most recent dicsussion of having a commons-vote list had pretty good
support but the thread died away.
Not having a dedicated place to vote is a continuous problem for
HttpClient, and would be for any other project that is looking towards
its own list. When we vote, we have to decide:
There is a vote on the commons-dev list to use the Base64 encoder from
HttpClient in the commons-codec package. If that passes we should
discuss using the the new package and deprecating/removing the fork in
HttpClient.
I think that this would be good for code reuse and for commons. If you
Its true that redirects to another host are very common. HttpMethod is
very anal about not redirecting to a new host or port or protocol. The
RFCs certainly allow that. There was state information that made it
unrealistic to forward outside the current connection.
But a lot has changed,
Hoegg
ISIS Networks
http://www.isisnetworks.net
Jeffrey Dever wrote:
There is a vote on the commons-dev list to use the Base64 encoder
from HttpClient in the commons-codec package. If that passes we
should discuss using the the new package and deprecating/removing the
fork in HttpClient.
I
Right, we should go back to the HttpClient to get another
HttpConnection. Perhaps the entire redirect mechanism should be pushed
up to the HttpClient class. I never liked the idea of a user holding
onto a HttpState, HttpMethod and HttpConnection and calling the
execute() method itself.
] Base64 class (based off of an old HttpClient
Base64) will be deprecated for a week and then removed.
Tim O'Brien
-Original Message-
From: Jeffrey Dever [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 03, 2003 2:02 PM
To: Commons HttpClient Project
Cc: [EMAIL PROTECTED
a bit of change. I am all for it, but that's would
spell quite a bit of change in just beginning to stabilize HttpClient's
Middle Earth. What's your call?
Oleg
On Mon, 2003-02-03 at 21:17, Jeffrey Dever wrote:
Right, we should go back to the HttpClient to get another
HttpConnection. Perhaps
Hey Eric,
I know I sounded rash. I just wanted to entice people that never post
to share their views, not incite revolt! I was also in a bit of a bad
mood when I sent that off. It showed. I try to build an image of being
level headed, but there I cracked.
* We should not remove
- no need for fully qualified class names in @see or @link comments
- please use @since 2.0beta1 new methods/classes
- don't see a need for getFirstHeader and getLastHeader
- getCondensedHeader, if there is one header, it returns a refrence to
an internal datastructure, if more than one, it
: Tomasz Pik [EMAIL PROTECTED]
Subject: Re: more common classes need a home
Jeffrey Dever wrote:
There are still a bunch of classes that are in both HttpClient and
Slide. In particular:
Base64.java
HttpsURL.java
HttpURL.java
URIException.java
URI.java
URIUtil.java
URLUtil.java
Base64
There are still a bunch of classes that are in both HttpClient and
Slide. In particular:
Base64.java
HttpsURL.java
HttpURL.java
URIException.java
URI.java
URIUtil.java
URLUtil.java
First of all, I think these should come out of Slide as part of their
migration to commons-httpclient which is
*commons.codec* sounds like a good place for this class. Perhaps you
could look at the various current implementations, and see if you can
provide a common Base64 class attractive to everyone in Jakarta.
Currently these projects (at least) have one plus your new codec package:
tomcat
Too may deprecation warnings for ya? Sorry about that.
I don't know why the tests all bothered to call useDisk(false), it was
the default anyway. I also see that finally deprecating those usdisk
methods has caused some gump warnings for Slide. I'll see what I can do
over there, but they
public void testConnectionPool()
throws IOException, HttpException
{
final MultiThreadedHttpConnectionManager manager = new
MultiThreadedHttpConnectionManager();
HttpClient httpClient = new HttpClient(manager);
There are still a bunch of classes that are in both HttpClient and
Slide. In particular:
Base64.java
HttpsURL.java
HttpURL.java
URIException.java
URI.java
URIUtil.java
URLUtil.java
First of all, I think these should come out of Slide as part of their
migration to commons-httpclient which is
What are HttpsURL and HttpURL generally used for?
Nothing. They are never even imported in httpclient classes, they are
just ghosts in some comments and log strings. Thats part of the reason
why I want to move them away from here. Also I don't find them a
particularly useful abstraction
I have almost started moving code of
PostMethod.generateRequestBody(NameValuePair[]) to URIUtils class, but
there's one point that made me reconsider. Currently URIUtils does not
know any HttpClient specific classes and that sort of makes sense. I am
not sure if we should make URIUtils be
I'd say that those Eclipse folks might find it an interesting idea to
toy with. It falls more into their area expertise. Any buddies involved
in Eclipse?
Naw, I'm just a user :-)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
The local and webapp tests are fine here (except that one timeout issue
that has been around for a while).
There are a few things that could be tweaked, but please submit the
patch so we can all benefit from it. Very high quality, great work!
Jandalf
Kalnichevski, Oleg wrote:
Bug fixes:
Squashed it. Good catch.
Laura Werner wrote:
I just noticed a minor bug in checkstyle.properties. There are two
settings for checkstyle.pattern.publicmember:
checkstyle.pattern.publicmember=^f[A-Z][a-zA-Z0-9]*$
and
checkstyle.pattern.publicmember=^[a-z][a-zA-Z0-9]*$
I'm not submitting a
It would be nice to have the javadoc generated for jakarta projects to
link internally to the actual Sun core api documentation. This was
easily accomplished with ant, but I'm not sure how to do that with maven.
It would probablly be nice to have a set of core javadoc for various
java
All good points. I had not yet had a chance to update those documents.
Its great to have input from everyone as the content is the hardest part.
I created a bug report for it and am refrencing back to this mail thread.
http://issues.apache.org/bugzilla/show_bug.cgi?id=16625
BTW: anyone can
I think that HttpClient was the last list to be partitioned. We are
quite happy with it. The issue that remains is with voting. We are
still part of commons and still want voting input from commons in
general. A *commons-vote* list would be very excellent in helping keep
us all together on
single component mailing lists
--
i think that single component mailing lists have not proved very
successful.
I completely disagree. As the HttpClient 2.0 release prime, I am
disheartened that you feel that way.
not only are they unpopular with the components
Good call.
[EMAIL PROTECTED] wrote:
The reason it's so wide is the blockquote in the HTML.
--
dIon Gillard, Multitask Consulting
Blog: http://www.freeroller.net/page/dion/Weblog
Work: http://www.multitask.com.au
Jeffrey Dever [EMAIL PROTECTED] wrote on 29/01/2003 01:32:59 PM
There has not been any more discussion on this topic so its time to call
a vote. Please vote on each entry with one of the following answers:
+1 agree
0 don't care
-1 disagree
For more information on what these mean, please see the email thread on
this and the checkstyle documentation:
My votes.
checkstyle.maxlinelen=100
+1
checkstyle.pattern.publicmember=^[a-z][a-zA-Z0-9]*$
+1
checkstyle.pattern.package=^[a-z]+(\.[a-z]*)*$
+1
checkstyle.header.file=license.regexp
checkstyle.header.regexp=true
+1
checkstyle.ignore.maxlinelen=Header:
+1
HttpClient.
As of the 2.0 Alpha 2 release, the maven checkstyle plugin produced
about 2500 style violations. We created a task to clean this up by the
beta release, and Mike has taken on this task.
There are a few other coding conventions used in other Jakarta projects,
as well as other
Yes. It started when I added the checkstyle.properties file. I don't
know why maven started handing off the html files to checkstyle, and
tried to fix it with those specific properties but they had no effect.
The report still generates OK, so I had not yet pursued it further.
Mike Bowler
I propose that we change the pattern for instance variables to
^_?[a-z][a-zA-Z0-9]*$ so that we will allow leading underscores but will
not insist on it.
Uuuugh, please no! Besides being ugly, it's worth sticking to the Sun
coding
style (as is the default with checkstyle). That way,
Ok, I thought we might wait on style related patches untill we finalize
some guidelines, but you have focused on issues not is dispute so thats
good. I do prefer patches to bugzilla, less traffic generated by email
(someone has to be paying for the apache bandwitdh).
Mike Bowler wrote:
I've
Hey Mike,
A couple issues with the patch. The tests failed due to a change to the
parameters member in HeaderElement. A protected member was made to be
private and given an accessor. I think that this is a good change, but
patches should pass the tests before they are posted. The tests were
Well, its related to the NTLM support in HttpClient. A few tests fail,
but I would suspect any NTLM use in 1.3 would fail similarly. Most of
the httpclient guys have been working on 1.4 (I did the release build in
1.4) and the gump builds don't fail so I guess its using 1.4 as well.
I've
We care!
[EMAIL PROTECTED] wrote:
Henri Yandell [EMAIL PROTECTED] wrote on 25/01/2003 05:33:50 AM:
On Fri, 24 Jan 2003, Craig R. McClanahan wrote:
I'm not a Maven guru, but it's not clear to me that the maven.xml and
project.xml files for all of the Commons projects have been kept up
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
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
For all current contributors and anyone wishing to contribute to
HttpClient, we are now in the Beta 1 development stage.
There is currently a rather complete list of bugs in bugzilla now. To
find them, do a query for the *Commons* project, *HttpClient* component,
and target milestone *2.0
1 - 100 of 123 matches
Mail list logo
