You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cactus-dev@jakarta.apache.org by Vincent Massol <vm...@pivolis.com> on 2004/03/15 22:48:00 UTC
[VOTE] Following HttpClient 3.x or staying with HttpClient 2.x?
Hi,
As you may have seen, there has been some gump failure emails for the
past 2 weeks or so. I've tracked the problem to some change to
HttpClient in CVS HEAD (v 3.x). It seems it was a regression. We were
not using the canonical way to perform basic authentication. I've now
just refactored our code to use the canonical way.
However, there are 2 problems remaining:
- HttpClient in HEAD depends on the Commons Codec jar. Thus we'll need
to add this dependency if we wish to be compatible with HttpClient 3.x
- v3.x of HttpClient will break several APIs and is not meant to be
backward compatible with version 2.x.
Question: what do we do?
Solution 1: we continue depending on v2.x of HttpClient. We upgrade our
Gump descriptor to use the "commons-httpclient-2.0-branch" projet. We'll
need to decide later on whether we want to upgrade to v3.x (for example
when v3.0 final is out).
Solution 2: we try to follow HttpClient's progression, knowing that
it'll be a bumpy ride. We also need to immediately add a dependency to
commons-codec.
My current feeling is that commons httpclient is some internal
implementation of Cactus and does not bring much added value to Cactus
users. Thus, I would prefer not to disturb Cactus users (like adding a
dependency on commons-codec). Thus I would be more inclined to solution
2. Actually, in the best of the possible world, the JDK should provide
commons HttpClient's features. +1 for solution 2 from me.
What do you think?
-Vincent
Wanna see JUnit in Action?
(http://manning.com/massol)
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
Re: [VOTE] Following HttpClient 3.x or staying with HttpClient 2.x?
Posted by Nicholas Lesiecki <nd...@yahoo.com>.
I'm +1 for sticking with 2.0. We can switch if we want to when they
have stabilized.
Cheers,
Nick
On Mar 15, 2004, at 10:43 PM, Vincent Massol wrote:
>
>
>> -----Original Message-----
>> From: Christopher Lenz [mailto:cmlenz@gmx.de]
>> Sent: 16 March 2004 00:28
>> To: Cactus Developers List
>> Subject: Re: [VOTE] Following HttpClient 3.x or staying with
> HttpClient
>> 2.x?
>>
>> Am 15.03.2004 um 22:48 schrieb Vincent Massol:
>>> As you may have seen, there has been some gump failure emails for
> the
>>> past 2 weeks or so. I've tracked the problem to some change to
>>> HttpClient in CVS HEAD (v 3.x). It seems it was a regression. We
> were
>>> not using the canonical way to perform basic authentication. I've
> now
>>> just refactored our code to use the canonical way.
>>>
>>> However, there are 2 problems remaining:
>>>
>>> - HttpClient in HEAD depends on the Commons Codec jar. Thus we'll
> need
>>> to add this dependency if we wish to be compatible with HttpClient
> 3.x
>>>
>>> - v3.x of HttpClient will break several APIs and is not meant to be
>>> backward compatible with version 2.x.
>>>
>>> Question: what do we do?
>>>
>>> Solution 1: we continue depending on v2.x of HttpClient. We upgrade
> our
>>> Gump descriptor to use the "commons-httpclient-2.0-branch" projet.
>>> We'll
>>> need to decide later on whether we want to upgrade to v3.x (for
> example
>>> when v3.0 final is out).
>>
>> +1
>>
>>> Solution 2: we try to follow HttpClient's progression, knowing that
>>> it'll be a bumpy ride. We also need to immediately add a dependency
> to
>>> commons-codec.
>>>
>>> My current feeling is that commons httpclient is some internal
>>> implementation of Cactus and does not bring much added value to
> Cactus
>>> users. Thus, I would prefer not to disturb Cactus users (like adding
> a
>>> dependency on commons-codec). Thus I would be more inclined to
> solution
>>> 2. Actually, in the best of the possible world, the JDK should
> provide
>>> commons HttpClient's features. +1 for solution 2 from me.
>>>
>>> What do you think?
>>
>> (Note that "+1 for solution 2" contradicts with the rest of what
> you've
>> written here, so I'm assuming you actually meant "+1 for solution
> 1"...
>> or maybe I've misunderstood)
>
> oooops :-) Yes, I meant +1 for solution 1.
>
>>
>> I agree with you. Let's stick to the 2.0 branch of HttpClient.
>>
>> To be fair, the HttpClient team has always been very clear that the
>> next release would break compatibility with 2.0, so this is not a
>> surprise.
>
> Yes, true.
>
> -Vincent
>
>>
>> Cheers,
>> Chris
>> --
>> Christopher Lenz
>> /=/ cmlenz at gmx.de
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
RE: [VOTE] Following HttpClient 3.x or staying with HttpClient 2.x?
Posted by Vincent Massol <vm...@pivolis.com>.
> -----Original Message-----
> From: Christopher Lenz [mailto:cmlenz@gmx.de]
> Sent: 16 March 2004 00:28
> To: Cactus Developers List
> Subject: Re: [VOTE] Following HttpClient 3.x or staying with
HttpClient
> 2.x?
>
> Am 15.03.2004 um 22:48 schrieb Vincent Massol:
> > As you may have seen, there has been some gump failure emails for
the
> > past 2 weeks or so. I've tracked the problem to some change to
> > HttpClient in CVS HEAD (v 3.x). It seems it was a regression. We
were
> > not using the canonical way to perform basic authentication. I've
now
> > just refactored our code to use the canonical way.
> >
> > However, there are 2 problems remaining:
> >
> > - HttpClient in HEAD depends on the Commons Codec jar. Thus we'll
need
> > to add this dependency if we wish to be compatible with HttpClient
3.x
> >
> > - v3.x of HttpClient will break several APIs and is not meant to be
> > backward compatible with version 2.x.
> >
> > Question: what do we do?
> >
> > Solution 1: we continue depending on v2.x of HttpClient. We upgrade
our
> > Gump descriptor to use the "commons-httpclient-2.0-branch" projet.
> > We'll
> > need to decide later on whether we want to upgrade to v3.x (for
example
> > when v3.0 final is out).
>
> +1
>
> > Solution 2: we try to follow HttpClient's progression, knowing that
> > it'll be a bumpy ride. We also need to immediately add a dependency
to
> > commons-codec.
> >
> > My current feeling is that commons httpclient is some internal
> > implementation of Cactus and does not bring much added value to
Cactus
> > users. Thus, I would prefer not to disturb Cactus users (like adding
a
> > dependency on commons-codec). Thus I would be more inclined to
solution
> > 2. Actually, in the best of the possible world, the JDK should
provide
> > commons HttpClient's features. +1 for solution 2 from me.
> >
> > What do you think?
>
> (Note that "+1 for solution 2" contradicts with the rest of what
you've
> written here, so I'm assuming you actually meant "+1 for solution
1"...
> or maybe I've misunderstood)
oooops :-) Yes, I meant +1 for solution 1.
>
> I agree with you. Let's stick to the 2.0 branch of HttpClient.
>
> To be fair, the HttpClient team has always been very clear that the
> next release would break compatibility with 2.0, so this is not a
> surprise.
Yes, true.
-Vincent
>
> Cheers,
> Chris
> --
> Christopher Lenz
> /=/ cmlenz at gmx.de
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
Re: [VOTE] Following HttpClient 3.x or staying with HttpClient 2.x?
Posted by Christopher Lenz <cm...@gmx.de>.
Am 15.03.2004 um 22:48 schrieb Vincent Massol:
> As you may have seen, there has been some gump failure emails for the
> past 2 weeks or so. I've tracked the problem to some change to
> HttpClient in CVS HEAD (v 3.x). It seems it was a regression. We were
> not using the canonical way to perform basic authentication. I've now
> just refactored our code to use the canonical way.
>
> However, there are 2 problems remaining:
>
> - HttpClient in HEAD depends on the Commons Codec jar. Thus we'll need
> to add this dependency if we wish to be compatible with HttpClient 3.x
>
> - v3.x of HttpClient will break several APIs and is not meant to be
> backward compatible with version 2.x.
>
> Question: what do we do?
>
> Solution 1: we continue depending on v2.x of HttpClient. We upgrade our
> Gump descriptor to use the "commons-httpclient-2.0-branch" projet.
> We'll
> need to decide later on whether we want to upgrade to v3.x (for example
> when v3.0 final is out).
+1
> Solution 2: we try to follow HttpClient's progression, knowing that
> it'll be a bumpy ride. We also need to immediately add a dependency to
> commons-codec.
>
> My current feeling is that commons httpclient is some internal
> implementation of Cactus and does not bring much added value to Cactus
> users. Thus, I would prefer not to disturb Cactus users (like adding a
> dependency on commons-codec). Thus I would be more inclined to solution
> 2. Actually, in the best of the possible world, the JDK should provide
> commons HttpClient's features. +1 for solution 2 from me.
>
> What do you think?
(Note that "+1 for solution 2" contradicts with the rest of what you've
written here, so I'm assuming you actually meant "+1 for solution 1"...
or maybe I've misunderstood)
I agree with you. Let's stick to the 2.0 branch of HttpClient.
To be fair, the HttpClient team has always been very clear that the
next release would break compatibility with 2.0, so this is not a
surprise.
Cheers,
Chris
--
Christopher Lenz
/=/ cmlenz at gmx.de
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org