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

2017-07-23 Thread 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: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



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

2017-07-23 Thread jaikiran
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 mailing thread.

I opened a dev mailing list thread to finalize this 
https://www.mail-archive.com/dev@ant.apache.org/msg45950.html


---
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 enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org



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

2017-07-23 Thread asfgit
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 enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org



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

2017-07-23 Thread jaikiran
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 can be 
configured on the resolver itself and that it looks more like an internal 
usage, I wouldn't expose this as an additional timeout attribute, especially 
since it's very specific to this resolver.

In general, I think the resolver(s) should use the named 
`timeout-constraint` for the common timeout concepts (like connection timeout 
and read timeout) and if necessary specify additional timeout details that are 
very specific to that resolver as specific attributes on the resolver's element 
itself.


---
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 enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org



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

2017-07-23 Thread 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: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org



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

2017-07-23 Thread twogee
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 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 enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org



Re: Opportunities for cohesion improvement and refatoring.

2017-07-23 Thread Stefan Bodewig
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

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org



Re: Opportunities for cohesion improvement and refatoring.

2017-07-23 Thread João Paulo Lemes Machado
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 class, he might consider creating it directly in the
JavadocConfig class, avoiding putting more methods into the Javadoc class.
And perhaps this strategy can be adopted for the creation of new classes in
the future.

For example, if you are going to create a new class that has a considerable
amount of gets () and sets () like Javadoc, you might consider creating a
configuration class for these methods.

I think if it is very difficult to correct what has already been done,
maybe we can avoid these problems in the future by adopting new practices
and strategies.

What do you think?

2017-07-23 7:47 GMT-03:00 Stefan Bodewig :

> 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 methods we want to extract as depreciated.
>
> > Then, we copy those methods to a new class.
>
> > So we will keep the methods in the original class for some time so that
> > developers who have some assumption about the class can adapt.
>
>
> > For example, the Javadoc has 114 methods, of which 64 are get () and set
> ()
> > methods. We could mark these methods as deprecated and copy them to a new
> > class: JavadocConfig, but we would leave them in the Javadoc class, and
> > they would be removed gradually.
>
>
> > Those parameters and methods would be accessed by an instance variable
> > in Javadoc.
>
>
>
> > However, when choosing the methods we could analyze their complexity. If
> it
> > is a simple set () or get () that only sets or returns a value it would
> be
> > prioritized.
>
>
>
> > Methods that have a greater complexity, or that make calls to other
> methods
> > would not be extracted at first.
>
>
>
> > What do you think about this strategy?
>
> This strategy is a sound strategy if you expect users of your API to
> follow releases closely. Unfortunately this is not what we see with Ant.
>
> Right now we are fielding a bug reported by somebody who is migrating
> from Ant 1.6.2 to 1.10.1 - 1.6.2 has been superseeded by 1.6.3 in
> 2005. This is not uncommon.
>
> People are using additional libraries like ant-contrib. ant-contrib has
> seen its last release in 2010 and it's development has stalled
> completely. We cannot remove any method used by it at all without
> breaking build files of people who rely on ant-contrib. Unfortunately
> ant-contrib is not the only example.
>
> This has led to us never removing any methods at all, no matter how long
> it has been deprecated. I'm not sure this is a good idea and not saying
> it has to stay that way, but the above has been the rationale for it.
>
> To be honest, I am one of the people who've upheld the "backwards
> compatible at all cost" mantra. Part of this may be due to the pain of
> "every release of Ant breaks my builds" threads around the release of
> Ant 1.2 (almost 17 years and I still recall it like yesterday, strange).
>
> If others feel it is time to revisit our extremely strong and at the
> same time limiting stance on backwards compatibility, I'll be listening
> to them.
>
> Stefan
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>


Re: Opportunities for cohesion improvement and refatoring.

2017-07-23 Thread Stefan Bodewig
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 methods we want to extract as depreciated.

> Then, we copy those methods to a new class.

> So we will keep the methods in the original class for some time so that
> developers who have some assumption about the class can adapt.


> For example, the Javadoc has 114 methods, of which 64 are get () and set ()
> methods. We could mark these methods as deprecated and copy them to a new
> class: JavadocConfig, but we would leave them in the Javadoc class, and
> they would be removed gradually.


> Those parameters and methods would be accessed by an instance variable
> in Javadoc.



> However, when choosing the methods we could analyze their complexity. If it
> is a simple set () or get () that only sets or returns a value it would be
> prioritized.



> Methods that have a greater complexity, or that make calls to other methods
> would not be extracted at first.



> What do you think about this strategy?

This strategy is a sound strategy if you expect users of your API to
follow releases closely. Unfortunately this is not what we see with Ant.

Right now we are fielding a bug reported by somebody who is migrating
from Ant 1.6.2 to 1.10.1 - 1.6.2 has been superseeded by 1.6.3 in
2005. This is not uncommon.

People are using additional libraries like ant-contrib. ant-contrib has
seen its last release in 2010 and it's development has stalled
completely. We cannot remove any method used by it at all without
breaking build files of people who rely on ant-contrib. Unfortunately
ant-contrib is not the only example.

This has led to us never removing any methods at all, no matter how long
it has been deprecated. I'm not sure this is a good idea and not saying
it has to stay that way, but the above has been the rationale for it.

To be honest, I am one of the people who've upheld the "backwards
compatible at all cost" mantra. Part of this may be due to the pain of
"every release of Ant breaks my builds" threads around the release of
Ant 1.2 (almost 17 years and I still recall it like yesterday, strange).

If others feel it is time to revisit our extremely strong and at the
same time limiting stance on backwards compatibility, I'll be listening
to them.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org



Re: Reproducible JARs

2017-07-23 Thread Stefan Bodewig
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 modification time, and
> re-zipping it. (Even if you were to touch the .class files in advance,
> there's MANIFEST.MF, which is created by Ant and which you have to
> unzip to access.)

The manifest may contain the current time stamp, to make things worse
for you :-)

I'm not sure what you want can be achieved at all. The best you can get
is the exact same jar when the build has been run on the same OS with
the same version of java, javac and zlib (and probably a few other
things I'm missing right now).

Different javacs will create different class files. ZIP (and thus JAR)
creation uses zlib under the covers and different versions may result in
different deflated output.

> Unless there's some efficient way of doing this that I've missed,
> could you advise me on how I'd go about writing a patch for Ant that
> makes reproducible JARs easier? I'd been thinking of adding a
> "modificationtime" attribute to the jar and zip tasks, and giving that
> time to all the files, but I'd be grateful if you could give me a
> rough idea of how Ant works and which files I'd need to be looking at
> and editing.

First of all you'd have to modify the class
org.apache.tools.ant.taskdefs.Zip and add a setModificationtime method
to it - this will create the attribute for both tasks, as the
implementation of  (org.apache.tools.ant.taskdefs.Jar) is a
subclass of the Zip class. You'll need to think about what the value of
the attribute should be - milliseconds since epoch? A formatted string
containing the timestamp to set?

And then you need to look for all places where Zip or Jar invoke setTime
on a ZipEntry instance.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org



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

2017-07-23 Thread Jaikiran Pai


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, in its own words, a
"Google friendly place for safe SEO", rather than the website of this
mailing list software. You might like to change it.

Ouch, thanks for pointing this out, fixed now. I wonder whether it has
always been wrong or djb gave up the domain and it has been repurposed.


It looks like the domain got repurposed sometime in 2012.

-Jaikiran

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org



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

2017-07-23 Thread Stefan Bodewig
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 place for safe SEO", rather than the website of this
> mailing list software. You might like to change it.

Ouch, thanks for pointing this out, fixed now. I wonder whether it has
always been wrong or djb gave up the domain and it has been repurposed.

Thanks

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org



Bug report for Ant [2017/07/23]

2017-07-23 Thread bugzilla
+---+
| Bugzilla Bug ID   |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned|
| | OPN=ReopenedVER=Verified(Skipped Closed/Resolved)   |
| |   +-+
| |   | Severity: BLK=Blocker CRI=Critical  REG=Regression  MAJ=Major   |
| |   |   MIN=Minor   NOR=NormalENH=Enhancement TRV=Trivial |
| |   |   +-+
| |   |   | Date Posted |
| |   |   |  +--+
| |   |   |  | Description  |
| |   |   |  |  |
| 5003|Opn|Blk|2001-11-21|exec task does not return after executed command f|
| 6606|Opn|Enh|2002-02-21|META-BUG problems with delegating classloaders|
| 7552|Opn|Cri|2002-03-28|Invalid task cache in targets |
| 7712|New|Enh|2002-04-03|Provide patternset support for VSSGET task?   |
| 8294|New|Enh|2002-04-19|: Allow  and  to app|
| 8866|New|Enh|2002-05-07|Signal handling in java task  |
| 8895|New|Enh|2002-05-08|ant and/or antcall should support forking |
| 8972|New|Enh|2002-05-10|allow property expansion in  property v|
| 8981|New|Enh|2002-05-10|Tar task command additional features  |
| 9294|New|Enh|2002-05-21|[PATCH] optional/j2ee/ServerDeploy OC4J Support   |
| 9995|Ass|Enh|2002-06-19|MKS Source Integrity tasks|
|10020|New|Enh|2002-06-19|'s dependency behaviour should be more con|
|10231|New|Enh|2002-06-25|Need access to current file in SQLExec|
|10283|New|Enh|2002-06-27|Add a destfile to the uptodate task   |
|10402|New|Enh|2002-07-02|adding the ability of html like whitespace preserv|
|3|New|Enh|2002-07-24|keytool task  |
|11560|Opn|Enh|2002-08-08|Taskdef does not apply reverseLoader policy on sta|
|12267|New|Enh|2002-09-03|Add ability to unzip into separate folders|
|12292|New|Enh|2002-09-04|[PATCH] enable  tag inside tar|
|12334|New|Enh|2002-09-05|REQUEST: Ant task doesn't allow attachment of a bu|
|12518|New|Enh|2002-09-11|Gunzip & BUnZip2 add filesets, patternsets, and ov|
|12765|New|Enh|2002-09-18|"rmdir" and "deltree" patches for ftp task enhance|
|12964|New|Enh|2002-09-24|ANTLR only takes one input file at a time |
|13047|Inf|Enh|2002-09-26|Support for  and  on O|
|13371|New|Enh|2002-10-07|[PATCH] Contributed new CvsExportDiff task|
|13847|New|Nor|2002-10-22|pvcs task: wrong option (-r) specified for get (sh|
|13934|New|Enh|2002-10-24|Translate task shouldn't load default locale prope|
|13939|New|Enh|2002-10-24|Translate task should have better key matching cap|
|14320|New|Enh|2002-11-06|copy fileset followsymlinks="false" does not copy |
|14393|New|Enh|2002-11-08|Support use of jndi within ant|
|14512|New|Enh|2002-11-13|Allow creating database connection similar to