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

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

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

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 clas

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

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 s

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

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) : > While it's fine to have such a dynamic behaviour it's hard to maintain. > On this special location - is it really requ

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

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 HttpClien

[GitHub] ant-ivy issue #54: IVY-735 Support timeouts on resolvers

Github user jaikiran commented on the issue: https://github.com/apache/ant-ivy/pull/54 >> So it's not going to work out supporting 2.x version since we will end up using 3.x APIs at compile time. But that's a different topic altogether and something that I will raise a dev list mailin

[GitHub] ant-ivy pull request #54: IVY-735 Support timeouts on resolvers

Github user asfgit closed the pull request at: https://github.com/apache/ant-ivy/pull/54 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enab

[GitHub] ant-ivy issue #54: IVY-735 Support timeouts on resolvers

Github user jaikiran commented on the issue: https://github.com/apache/ant-ivy/pull/54 >> VsftpRepository has DEFAULT_READ_TIMEOUT and DISCONNECT_COMMAND_TIMEOUT; would that require an additional timeout attribute? I had a look at this. Given that there's currently no way it c

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 w

[GitHub] ant-ivy issue #54: IVY-735 Support timeouts on resolvers

Github user twogee commented on the issue: https://github.com/apache/ant-ivy/pull/54 I'd rather have dropping support for 2.x up for vote a.s.a.p. because 3.x is [EOL](http://hc.apache.org/httpclient-3.x/) already. --- If your project is set up for it, you can reply to this email and

Re: Opportunities for cohesion improvement and refatoring.

On 2017-07-23, João Paulo Lemes Machado wrote: > Thank you Stefan. > I did not know that the issue of break of build was so serious. > However, I still think that creating a class for the configuration methods > can help prevent these classes from growing even more. Absolutely. Stefan

Re: Opportunities for cohesion improvement and refatoring.

Thank you Stefan. I did not know that the issue of break of build was so serious. However, I still think that creating a class for the configuration methods can help prevent these classes from growing even more. For example if someone wants to create a new get () or set () method for the Javadoc

Re: Opportunities for cohesion improvement and refatoring.

On 2017-07-23, João Paulo Lemes Machado wrote: > Analyzing the points of our discussion, I have realized that the most > critical problem is the dependence these classes may have on other classes. > With that in mind I recommend a gradual refactoring that works as follows: > First, we mark the m

Re: Reproducible JARs

On 2017-07-22, George Bateman wrote: > I'm currently trying to make Processing build > reproducibly (so building it twice yields the exact same output file). > Currently this involves, as far as I can tell, unzipping every JAR > file, touching the files with a constant mod

Re: Broken link at https://ant.apache.org/mail.html

On 23/07/17 3:50 PM, Stefan Bodewig wrote: On 2017-07-22, George Bateman wrote: On subscribing to this list, I noticed that the link at the end of In your first email you will get some information about working with the list manager EZMLM. goes to http://www.ezmlm.org/, which is actually, i

Re: Broken link at https://ant.apache.org/mail.html

On 2017-07-22, George Bateman wrote: > On subscribing to this list, I noticed that the link at the end of >> In your first email you will get some information about working with the >> list manager EZMLM. > goes to http://www.ezmlm.org/, which is actually, in its own words, a > "Google friendly

Bug report for Ant [2017/07/23]

+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned