[Bug 63248] [PATCH] FTP action "feat" support
https://bz.apache.org/bugzilla/show_bug.cgi?id=63248
--- Comment #2 from Jaikiran Pai ---
I had a look at the patch and it looks mostly fine to me. Except this bit:
> +if (ftp.sendCommand("FEAT") != 211) {
> +log("Failed to issue Feat Command: ", Project.MSG_WARN);
I read the RFC for this command[1]. It states that:
> Where a server-FTP process does not support the FEAT command, it will
> respond to the FEAT command with a 500 or 502 reply. This is simply
> the normal "unrecognized command" reply that any unknown command
> would elicit. Errors in the command syntax, such as giving
> parameters, will result in a 501 reply.
>
> Server-FTP processes that recognize the FEAT command, but implement
> no extended features, and therefore have nothing to report, SHOULD
> respond with the "no-features" 211 reply. However, as this case is
> practically indistinguishable from a server-FTP that does not
> recognize the FEAT command, a 500 or 502 reply MAY also be used. The
> "no-features" reply MUST NOT use the multi-line response format,
> exactly one response line is required and permitted.
So based on that, a response code of 211 implies no-features. However, in the
patch, the code expects a 211 response and only then considers the rest of the
reply strings and prints them out. That looks wrong IMO.
[1] https://tools.ietf.org/html/rfc2389
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 63252] [PATCH] FTP prevent No Transfer Timeout during long listings
https://bz.apache.org/bugzilla/show_bug.cgi?id=63252 --- Comment #2 from Jaikiran Pai --- I had a look at the patch. Upon the "idle" timeout being reached, as you note, you trigger a command from the client, which happens to be: > The command used to trigger a data connection is a LIST on the current file > being parsed by the listing. IMO, the list command can be potentially expensive (imagine it getting triggered on a directory), more so because we aren't really interested in what it returns. Instead of issuing a list command, can you instead issue a "NOOP" command, available via the FTPClient#sendNoOp() which as per the javadoc of this method is meant to be used in cases like this one? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 63259] [PATCH] FTP symlinks are checked twice
https://bz.apache.org/bugzilla/show_bug.cgi?id=63259 Jaikiran Pai changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |1.10.7 Status|NEW |RESOLVED --- Comment #2 from Jaikiran Pai --- Hello Eugène, Thank you for the patch. I've reviewed it and it looks fine to me. I made a minor change to the comment in the patch and merged this upstream https://gitbox.apache.org/repos/asf?p=ant.git;a=commitdiff;h=0259c0b981e997a67a926c5303e8906250b30bb6 -- You are receiving this mail because: You are the assignee for the bug.
[ant] branch master updated: bz-63259 Don't check the FTP file for being a symlink, more than once
This is an automated email from the ASF dual-hosted git repository.
jaikiran pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/ant.git
The following commit(s) were added to refs/heads/master by this push:
new 0259c0b bz-63259 Don't check the FTP file for being a symlink, more
than once
0259c0b is described below
commit 0259c0b981e997a67a926c5303e8906250b30bb6
Author: Jaikiran Pai
AuthorDate: Fri May 17 09:51:46 2019 +0530
bz-63259 Don't check the FTP file for being a symlink, more than once
Patch contributed by Eugène Adell, as an attachment in the bugzilla issue.
Signed-off-by: Jaikiran Pai
---
WHATSNEW | 6 ++
src/main/org/apache/tools/ant/taskdefs/optional/net/FTP.java | 4 +++-
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/WHATSNEW b/WHATSNEW
index b88b95f..86f2e4c 100644
--- a/WHATSNEW
+++ b/WHATSNEW
@@ -1,6 +1,12 @@
Changes from Ant 1.10.6 TO Ant 1.10.7
=
+Fixed bugs:
+---
+
+ * FTP task no longer duplicates a check for a file being a symlink.
+ Bugzilla Report 63259
+
Changes from Ant 1.10.5 TO Ant 1.10.6
=
diff --git a/src/main/org/apache/tools/ant/taskdefs/optional/net/FTP.java
b/src/main/org/apache/tools/ant/taskdefs/optional/net/FTP.java
index fe757e2..5838e1e 100644
--- a/src/main/org/apache/tools/ant/taskdefs/optional/net/FTP.java
+++ b/src/main/org/apache/tools/ant/taskdefs/optional/net/FTP.java
@@ -537,7 +537,9 @@ public class FTP extends Task implements FTPTaskConfig {
} else {
if (!isFollowSymlinks() && file.isSymbolicLink()) {
filesExcluded.addElement(name);
-} else if (isFunctioningAsFile(ftp, dir, file)) {
+} else {
+// at this point, it's either a symbolic link
or a file, but not a directory.
+// so we include it
accountForIncludedFile(name);
}
}
[Bug 63071] CCCheckout task does not honor "failonerr=true" for lsCheckout call
https://bz.apache.org/bugzilla/show_bug.cgi?id=63071 william.rup...@oracle.com changed: What|Removed |Added Status|RESOLVED|VERIFIED --- Comment #2 from william.rup...@oracle.com --- Confirmed fixed in 1.10.6. Thanks! -- You are receiving this mail because: You are the assignee for the bug.
[Bug 63438] javadoc-target fails when any OPTIONAL dependencies are missing
https://bz.apache.org/bugzilla/show_bug.cgi?id=63438 --- Comment #4 from Mikhail T. --- (In reply to Jaikiran Pai from comment #3) > But before getting to any of that Let's implement the fixes in parallel with -- rather than after -- figuring out, why JDK is the way it is... -- You are receiving this mail because: You are the assignee for the bug.
[Bug 63438] javadoc-target fails when any OPTIONAL dependencies are missing
https://bz.apache.org/bugzilla/show_bug.cgi?id=63438 --- Comment #3 from Jaikiran Pai --- What I meant in my previous reply was that, based on the documentation of the javadoc tool shipped in the JDK (the one which we use in that task), I don't expect that tool to fail with an error in first place for such references and thus the failonerror attribute of that task shouldn't play a role. I agree ultimately this might (and probably will) need a change to our build.xml file to either allow configuring the failonerror value for this target or make some kind of path exclusions or maybe even pass along a -Xdoclint option to that task to use something like "-Xdoclint:all,-reference". But beforing getting to any of that, I personally am interested in understanding why the JDK shipped javadoc tool is failing in first place. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 63438] javadoc-target fails when any OPTIONAL dependencies are missing
https://bz.apache.org/bugzilla/show_bug.cgi?id=63438 --- Comment #2 from Mikhail T. --- (In reply to Jaikiran Pai from comment #1) > However, I'm unsure why the javadoc tools errors out in such cases It errors out because of the explicit "failonerror=true" in the element :) The quick-dirty workaround is to simply flip the above setting to false -- as I'm already doing in my update to FreeBSD port devel/apache-ant (see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237913) The proper fix, I guess, is to painstakingly exclude the sources dependent on the missing optional dependencies from Javadoc as they are already excluded from compilation... Then the failonerror can be proudly set back to true again... -- You are receiving this mail because: You are the assignee for the bug.
[Bug 63438] javadoc-target fails when any OPTIONAL dependencies are missing
https://bz.apache.org/bugzilla/show_bug.cgi?id=63438 --- Comment #1 from Jaikiran Pai --- I was able to reproduce this. The javadoc tool seems to error out and exit with a non-zero exit code when it cannot resolve a "reference". You can, in fact, find 26 "reference not found" errors which match with the final "26 errors" summary message in that log you attached. These references are mostly of the form @throws JSchException, @see and such. It's understandable why those references aren't found. However, I'm unsure why the javadoc tools errors out in such cases and thus contradicting with what it says on it's documentation page[1] for Java 1.8 (the version you are using): "Reports warnings for bad references... ... Messages may be either warnings or errors, depending on their severity and the likelihood to cause an error if the generated documentation were run through a validator. For example, bad references or missing Javadoc comments do not cause the javadoc command to generate invalid HTML, so these issues are reported as warnings." I've asked for clarification about this on the openjdk javadoc-dev mailing list and will decide how we can proceed with this one, once we get clarity on the matter. [1] https://docs.oracle.com/javase/8/docs/technotes/tools/unix/javadoc.html#CHDCIBFC -- You are receiving this mail because: You are the assignee for the bug.
