ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gintautas Grigelionis <g.grigelio...@gmail.com>
Subject Re: Ivy - No more support for commons-httpclient 2.x in runtime classpath?
Date Mon, 24 Jul 2017 06:07:17 GMT
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) <apache@materne.de>:

> 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:jai.forums2013@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-unsubscribe@ant.apache.org For additional
> > commands, e-mail: dev-help@ant.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message