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:jai.forums2...@gmail.com]
Gesendet: Montag, 24. Juli 2017 07:25
An: dev@ant.apache.org
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: dev-unsubscr...@ant.apache.org For additional
commands, e-mail: dev-h...@ant.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
