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

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

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

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,

Bug report for Ant [2017/07/23]

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

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

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

[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

[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

[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

[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

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