[GitHub] ant issue #54: Let’s use Ivy (properly!) and drop Maven Ant tasks + Common...
Github user asfgit commented on the issue: https://github.com/apache/ant/pull/54 Refer to this link for build results (access rights to CI server needed): https://builds.apache.org/job/Ant%20Github-PR-Windows/64/ --- - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
[GitHub] ant issue #54: Let’s use Ivy (properly!) and drop Maven Ant tasks + Common...
Github user asfgit commented on the issue: https://github.com/apache/ant/pull/54 Refer to this link for build results (access rights to CI server needed): https://builds.apache.org/job/Ant%20Github-PR-Linux/58/ --- - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Bz 62324
2018-06-09 13:56 GMT+02:00 Jaikiran Pai : > > On 09/06/18 5:22 PM, Gintautas Grigelionis wrote: > >> >> Thanks for review, Jaikiran. You're correct, that is the proposed >> solution, >> adding a separator >> (a newline followed by an exception name for clarity -- mind that >> exception >> is logged only in debug mode). >> > The exception class name would already be part of the stacktrace anyway, > so IMO, that wouldn't be of much use. Plus the bugzilla > description/comments state that the thing that's being logged twice is a > message (is it the message from the exception class?). So even with this > change, it will still end up being logged twice right? > Yes, but the double logging only occurs in debug mode AND when the message is encapsulated in the exception which is added to the same event. By the way, is this issue specific to the delete task? > I didn't investigate, because it is not easy to figure out if a task creates an event which contains a message both per se and encapsulated in an exception. Gintas
Re: Bz 62324
On 09/06/18 5:22 PM, Gintautas Grigelionis wrote: Thanks for review, Jaikiran. You're correct, that is the proposed solution, adding a separator (a newline followed by an exception name for clarity -- mind that exception is logged only in debug mode). The exception class name would already be part of the stacktrace anyway, so IMO, that wouldn't be of much use. Plus the bugzilla description/comments state that the thing that's being logged twice is a message (is it the message from the exception class?). So even with this change, it will still end up being logged twice right? By the way, is this issue specific to the delete task? -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Bz 62324
2018-06-09 13:31 GMT+02:00 Jaikiran Pai : > For easy reference, the bug in discussion is this one > https://bz.apache.org/bugzilla/show_bug.cgi?id=62324 > > > On 09/06/18 12:38 AM, Gintautas Grigelionis wrote: > >> Namely, a stack trace of the exception is logged (in debug mode only) >> without any separator from the preceding message. While it seems that the >> idea is that the stack trace should be presented as a continuation of the >> message, IMO it would require a specially formatted message or, well, some >> separator to be visually consistent. >> >> So the question is whether there is better solution than the one currently >> proposed? >> > I saw a commit that was made linking to this bug > https://github.com/apache/ant/commit/69a3f1c1577ef0cf43d2a93 > 4a109cb0843c5b754. Is that the proposed solution? > > I haven't investigated the issue myself, but I can't relate that commit as > a solution to what's being discussed in that bug. If I understand it > correctly, the commit seems to be now using the exception class' simple > name (which by the way can be obtained by getClass().getSimpleName() > instead of substring substitutions) and printing a newline and the > exception class simple name and then follows it with the complete > stacktrace. Earlier, before this commit, it used to print just the > stacktrace. I don't see how this change would solve what's being discussed > in that bugzilla. > > If this isn't the proposed solution, is there some other place I can read > up on what's being proposed? > > > -Jaikiran > Thanks for review, Jaikiran. You're correct, that is the proposed solution, adding a separator (a newline followed by an exception name for clarity -- mind that exception is logged only in debug mode). Gintas
Re: javadoc in Java 10+
2018-06-09 12:54 GMT+02:00 Stefan Bodewig : > On 2018-06-09, Gintautas Grigelionis wrote: > > > ... needs a -html4 or -html5 option, otherwise the standard doclet emits > a > > warning. Something for Bugzilla? > > +1 > > Stefan > Please see https://bz.apache.org/bugzilla/show_bug.cgi?id=6244 Gintas
Re: Bz 62324
For easy reference, the bug in discussion is this one https://bz.apache.org/bugzilla/show_bug.cgi?id=62324 On 09/06/18 12:38 AM, Gintautas Grigelionis wrote: Namely, a stack trace of the exception is logged (in debug mode only) without any separator from the preceding message. While it seems that the idea is that the stack trace should be presented as a continuation of the message, IMO it would require a specially formatted message or, well, some separator to be visually consistent. So the question is whether there is better solution than the one currently proposed? I saw a commit that was made linking to this bug https://github.com/apache/ant/commit/69a3f1c1577ef0cf43d2a934a109cb0843c5b754. Is that the proposed solution? I haven't investigated the issue myself, but I can't relate that commit as a solution to what's being discussed in that bug. If I understand it correctly, the commit seems to be now using the exception class' simple name (which by the way can be obtained by getClass().getSimpleName() instead of substring substitutions) and printing a newline and the exception class simple name and then follows it with the complete stacktrace. Earlier, before this commit, it used to print just the stacktrace. I don't see how this change would solve what's being discussed in that bugzilla. If this isn't the proposed solution, is there some other place I can read up on what's being proposed? -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: javadoc in Java 10+
On 2018-06-09, Gintautas Grigelionis wrote: > ... needs a -html4 or -html5 option, otherwise the standard doclet emits a > warning. Something for Bugzilla? +1 Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
javadoc in Java 10+
... needs a -html4 or -html5 option, otherwise the standard doclet emits a warning. Something for Bugzilla? Gintas
Re: Tooling update
Thanks, Stefan. Meanwhile, SpotBugs is reactivated in the nighlies now. I noticed, however, that execution order is important: if SpotBugs runs before Checkstyle, the latter bails out because of ANTLR. Gintas 2018-06-08 20:42 GMT+02:00 Stefan Bodewig : > On 2018-06-08, Gintautas Grigelionis wrote: > > > Then I was surprised that Dependency Check indicates that the latest > > XZ 1.8 has a vulnerability: should we ask them to investigate? > > That's a false positive. > > https://www.cvedetails.com/cve/CVE-2015-4035/ applies to the command > line tooling and is not related to XZ for Java at all. > > Stefan > > - > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > For additional commands, e-mail: dev-h...@ant.apache.org > >