Ivy - No more support for commons-httpclient 2.x in runtime classpath?

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Ivy - No more support for commons-httpclient 2.x in runtime classpath?

Jaikiran Pai
Ivy currently uses commons-httpclient for dealing with HTTP
repositories. This is an internal implementation detail of Ivy. The way
it's implemented, it allows the user to use a version of their choice,
of this library, by placing them in the runtime classpath (similar to
some other libraries we use). The implementation internally checks for
the presence of 2.x as well as 3.x version of library to decide which
version to use at _runtime_ [1].

At compile time, we use 3.x version of the library[2]. This leaves us in
a bit of a problem in that if we use the recommended APIs in 3.x (at
compile time) instead of the deprecated 2.x APIs or any 3.x API for that
matter in our code, unless we mandate 3.x version of the library at
runtime, users can run into classloading/library issues. Plus the fact
that we can't easily support this 2.x vs 3.x usage in the same Ivy codebase.

So what I would like to propose is that for the upcoming release, we
mandate 3.x as the version that we support and expect users to have that
version of their library in the runtime classpath. In other words, we no
longer support 2.x of commons-httpclient in the upcoming release. That
will make it much more easier to manage the internal implementation
details without having to juggle with versions of the library.

Any thoughts?

[1]
https://github.com/apache/ant-ivy/blob/master/src/java/org/apache/ivy/util/url/HttpClientHandler.java#L224

[2] https://github.com/apache/ant-ivy/blob/master/ivy.xml#L47


-Jaikiran



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

AW: Ivy - No more support for commons-httpclient 2.x in runtime classpath?

Jan Matèrne (jhm)
While it's fine to have such a dynamic behaviour it's hard to maintain.
On this special location - is it really required or could we use a fixed version
(like current HttpComponents Client)
  https://hc.apache.org/:
  "HttpComponents Client is a successor of and replacement for Commons HttpClient 3.x.
  Users of Commons HttpClient are strongly encouraged to upgrade."


So I'm +1 in dropping commons-http-2 support.
What about dropping commons-http-3 too? Here I can't see the requirement for having this
dynamic loading (but maybe someone else).


Jan


> -----Ursprüngliche Nachricht-----
> Von: Jaikiran Pai [mailto:[hidden email]]
> Gesendet: Montag, 24. Juli 2017 07:25
> An: [hidden email]
> Betreff: Ivy - No more support for commons-httpclient 2.x in runtime
> classpath?
>
> Ivy currently uses commons-httpclient for dealing with HTTP
> repositories. This is an internal implementation detail of Ivy. The way
> it's implemented, it allows the user to use a version of their choice,
> of this library, by placing them in the runtime classpath (similar to
> some other libraries we use). The implementation internally checks for
> the presence of 2.x as well as 3.x version of library to decide which
> version to use at _runtime_ [1].
>
> At compile time, we use 3.x version of the library[2]. This leaves us
> in a bit of a problem in that if we use the recommended APIs in 3.x (at
> compile time) instead of the deprecated 2.x APIs or any 3.x API for
> that matter in our code, unless we mandate 3.x version of the library
> at runtime, users can run into classloading/library issues. Plus the
> fact that we can't easily support this 2.x vs 3.x usage in the same Ivy
> codebase.
>
> So what I would like to propose is that for the upcoming release, we
> mandate 3.x as the version that we support and expect users to have
> that version of their library in the runtime classpath. In other words,
> we no longer support 2.x of commons-httpclient in the upcoming release.
> That will make it much more easier to manage the internal
> implementation details without having to juggle with versions of the
> library.
>
> Any thoughts?
>
> [1]
> https://github.com/apache/ant-
> ivy/blob/master/src/java/org/apache/ivy/util/url/HttpClientHandler.java
> #L224
>
> [2] https://github.com/apache/ant-ivy/blob/master/ivy.xml#L47
>
>
> -Jaikiran
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email] For additional
> commands, e-mail: [hidden email]



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Ivy - No more support for commons-httpclient 2.x in runtime classpath?

Gintautas Grigelionis
FYI 2.x is EOL for 11.5 years [1]

Should we count each year as +1? :-)

Gintas

[1] http://hc.apache.org/httpclient-3.x/news.html

2017-07-24 7:53 GMT+02:00 Jan Matèrne (jhm) <[hidden email]>:

> While it's fine to have such a dynamic behaviour it's hard to maintain.
> On this special location - is it really required or could we use a fixed
> version
> (like current HttpComponents Client)
>   https://hc.apache.org/:
>   "HttpComponents Client is a successor of and replacement for Commons
> HttpClient 3.x.
>   Users of Commons HttpClient are strongly encouraged to upgrade."
>
>
> So I'm +1 in dropping commons-http-2 support.
> What about dropping commons-http-3 too? Here I can't see the requirement
> for having this
> dynamic loading (but maybe someone else).
>
>
> Jan
>
>
> > -----Ursprüngliche Nachricht-----
> > Von: Jaikiran Pai [mailto:[hidden email]]
> > Gesendet: Montag, 24. Juli 2017 07:25
> > An: [hidden email]
> > Betreff: Ivy - No more support for commons-httpclient 2.x in runtime
> > classpath?
> >
> > Ivy currently uses commons-httpclient for dealing with HTTP
> > repositories. This is an internal implementation detail of Ivy. The way
> > it's implemented, it allows the user to use a version of their choice,
> > of this library, by placing them in the runtime classpath (similar to
> > some other libraries we use). The implementation internally checks for
> > the presence of 2.x as well as 3.x version of library to decide which
> > version to use at _runtime_ [1].
> >
> > At compile time, we use 3.x version of the library[2]. This leaves us
> > in a bit of a problem in that if we use the recommended APIs in 3.x (at
> > compile time) instead of the deprecated 2.x APIs or any 3.x API for
> > that matter in our code, unless we mandate 3.x version of the library
> > at runtime, users can run into classloading/library issues. Plus the
> > fact that we can't easily support this 2.x vs 3.x usage in the same Ivy
> > codebase.
> >
> > So what I would like to propose is that for the upcoming release, we
> > mandate 3.x as the version that we support and expect users to have
> > that version of their library in the runtime classpath. In other words,
> > we no longer support 2.x of commons-httpclient in the upcoming release.
> > That will make it much more easier to manage the internal
> > implementation details without having to juggle with versions of the
> > library.
> >
> > Any thoughts?
> >
> > [1]
> > https://github.com/apache/ant-
> > ivy/blob/master/src/java/org/apache/ivy/util/url/HttpClientHandler.java
> > #L224
> >
> > [2] https://github.com/apache/ant-ivy/blob/master/ivy.xml#L47
> >
> >
> > -Jaikiran
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email] For additional
> > commands, e-mail: [hidden email]
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: AW: Ivy - No more support for commons-httpclient 2.x in runtime classpath?

Jaikiran Pai
In reply to this post by Jan Matèrne (jhm)

On 24/07/17 11:23 AM, Jan Matèrne (jhm) wrote:
> While it's fine to have such a dynamic behaviour it's hard to maintain.
> On this special location - is it really required or could we use a fixed version
> (like current HttpComponents Client)
>    https://hc.apache.org/:
>    "HttpComponents Client is a successor of and replacement for Commons HttpClient 3.x.
>    Users of Commons HttpClient are strongly encouraged to upgrade."
I had been involved in a different project where we moved from Commons
HttpClient 3.x to HttpComponents Client. The APIs, package names and
some of the constructs have all changed in that new version. So moving
to that version involves almost completely rewriting the integration
layer. Having said that, it's a good version to move to (given the
enhancements it brings in). I wasn't planning to move to that newer
library in this release, but now that I am in that part of the code, I
decided to take a much closer look of how easy/difficult (from a
development point of view) this task is going to be. From a development
point of view, it doesn't look like it's a very big task to move to this
newer version given that most of our (internal) code interaction happens
via a in-house wrapper interface over the HTTP client library. I have
some spare hours later today, I'll see if I can come up with a patch
that's functionally equivalent to what we have currently in Ivy with
this newer library.

In short, dropping commons-httpclient 3.x and moving to the more latest
HttpComponents Client sounds fine to me.

-Jaikiran

>
> So I'm +1 in dropping commons-http-2 support.
> What about dropping commons-http-3 too? Here I can't see the requirement for having this
> dynamic loading (but maybe someone else).
>
>
> Jan
>
>
>> -----Ursprüngliche Nachricht-----
>> Von: Jaikiran Pai [mailto:[hidden email]]
>> Gesendet: Montag, 24. Juli 2017 07:25
>> An: [hidden email]
>> Betreff: Ivy - No more support for commons-httpclient 2.x in runtime
>> classpath?
>>
>> Ivy currently uses commons-httpclient for dealing with HTTP
>> repositories. This is an internal implementation detail of Ivy. The way
>> it's implemented, it allows the user to use a version of their choice,
>> of this library, by placing them in the runtime classpath (similar to
>> some other libraries we use). The implementation internally checks for
>> the presence of 2.x as well as 3.x version of library to decide which
>> version to use at _runtime_ [1].
>>
>> At compile time, we use 3.x version of the library[2]. This leaves us
>> in a bit of a problem in that if we use the recommended APIs in 3.x (at
>> compile time) instead of the deprecated 2.x APIs or any 3.x API for
>> that matter in our code, unless we mandate 3.x version of the library
>> at runtime, users can run into classloading/library issues. Plus the
>> fact that we can't easily support this 2.x vs 3.x usage in the same Ivy
>> codebase.
>>
>> So what I would like to propose is that for the upcoming release, we
>> mandate 3.x as the version that we support and expect users to have
>> that version of their library in the runtime classpath. In other words,
>> we no longer support 2.x of commons-httpclient in the upcoming release.
>> That will make it much more easier to manage the internal
>> implementation details without having to juggle with versions of the
>> library.
>>
>> Any thoughts?
>>
>> [1]
>> https://github.com/apache/ant-
>> ivy/blob/master/src/java/org/apache/ivy/util/url/HttpClientHandler.java
>> #L224
>>
>> [2] https://github.com/apache/ant-ivy/blob/master/ivy.xml#L47
>>
>>
>> -Jaikiran
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email] For additional
>> commands, e-mail: [hidden email]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Ivy - No more support for commons-httpclient 2.x in runtime classpath?

Stefan Bodewig
In reply to this post by Jaikiran Pai
On 2017-07-24, Jaikiran Pai wrote:

> Ivy currently uses commons-httpclient for dealing with HTTP
> repositories. This is an internal implementation detail of Ivy. The
> way it's implemented, it allows the user to use a version of their
> choice, of this library, by placing them in the runtime classpath
> (similar to some other libraries we use). The implementation
> internally checks for the presence of 2.x as well as 3.x version of
> library to decide which version to use at _runtime_ .

Let me point out that even 3.x has long reached end of life. It's
successor fixed CVE-2012-5783[1] with 4.2.3 but there hasn't been any
3.x release that has fixed it AFAIK.

Stefan

[1] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-5783

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Ivy - No more support for commons-httpclient 2.x in runtime classpath?

Jaikiran Pai
That's a a big enough reason to move to HttpComponents Client 4.x
version! I'll have that done in this release of Ivy then.

-Jaikiran


On 24/07/17 11:43 AM, Stefan Bodewig wrote:

> On 2017-07-24, Jaikiran Pai wrote:
>
>> Ivy currently uses commons-httpclient for dealing with HTTP
>> repositories. This is an internal implementation detail of Ivy. The
>> way it's implemented, it allows the user to use a version of their
>> choice, of this library, by placing them in the runtime classpath
>> (similar to some other libraries we use). The implementation
>> internally checks for the presence of 2.x as well as 3.x version of
>> library to decide which version to use at _runtime_ .
> Let me point out that even 3.x has long reached end of life. It's
> successor fixed CVE-2012-5783[1] with 4.2.3 but there hasn't been any
> 3.x release that has fixed it AFAIK.
>
> Stefan
>
> [1] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-5783
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Ivy - No more support for commons-httpclient 2.x in runtime classpath?

Nicolas Lalevée

> Le 24 juil. 2017 à 08:19, Jaikiran Pai <[hidden email]> a écrit :
>
> That's a a big enough reason to move to HttpComponents Client 4.x version! I'll have that done in this release of Ivy then.

+1

Nicolas

>
> -Jaikiran
>
>
> On 24/07/17 11:43 AM, Stefan Bodewig wrote:
>> On 2017-07-24, Jaikiran Pai wrote:
>>
>>> Ivy currently uses commons-httpclient for dealing with HTTP
>>> repositories. This is an internal implementation detail of Ivy. The
>>> way it's implemented, it allows the user to use a version of their
>>> choice, of this library, by placing them in the runtime classpath
>>> (similar to some other libraries we use). The implementation
>>> internally checks for the presence of 2.x as well as 3.x version of
>>> library to decide which version to use at _runtime_ .
>> Let me point out that even 3.x has long reached end of life. It's
>> successor fixed CVE-2012-5783[1] with 4.2.3 but there hasn't been any
>> 3.x release that has fixed it AFAIK.
>>
>> Stefan
>>
>> [1] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-5783
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Ivy - No more support for commons-httpclient 2.x in runtime classpath?

Jaikiran Pai
This turned out to be a relatively smaller task than what I had
previously thought it would be. That's mainly thanks to the way this
whole interaction with the library, in Ivy, has been designed and kept
isolated from majority of the code.

So as of late yesterday, the master branch now uses 4.5.3 of
HttpComponents HttpClient library. Relevant documentation has been
updated to reflect the same. Additional tests have been added to
test/verify the semantics and also verify some of the issues that were
reported in Ivy due to our usage of the older commons-httpclient.

An upstream master build on Jenkins after these commits has gone fine
too. I'm waiting for at least another round of Jenkins job to finish
(for unrelated reasons our jobs haven't triggered given unavailability
of some Jenkins agents/nodes), before I request some of our users on
ivy-user mailing list to give the latest snapshot a try to see if there
are any unforeseen regressions.

-Jaikiran
On 25/07/17 12:37 AM, Nicolas Lalevée wrote:

>> Le 24 juil. 2017 à 08:19, Jaikiran Pai <[hidden email]> a écrit :
>>
>> That's a a big enough reason to move to HttpComponents Client 4.x version! I'll have that done in this release of Ivy then.
> +1
>
> Nicolas
>
>> -Jaikiran
>>
>>
>> On 24/07/17 11:43 AM, Stefan Bodewig wrote:
>>> On 2017-07-24, Jaikiran Pai wrote:
>>>
>>>> Ivy currently uses commons-httpclient for dealing with HTTP
>>>> repositories. This is an internal implementation detail of Ivy. The
>>>> way it's implemented, it allows the user to use a version of their
>>>> choice, of this library, by placing them in the runtime classpath
>>>> (similar to some other libraries we use). The implementation
>>>> internally checks for the presence of 2.x as well as 3.x version of
>>>> library to decide which version to use at _runtime_ .
>>> Let me point out that even 3.x has long reached end of life. It's
>>> successor fixed CVE-2012-5783[1] with 4.2.3 but there hasn't been any
>>> 3.x release that has fixed it AFAIK.
>>>
>>> Stefan
>>>
>>> [1] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-5783
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Loading...