[GitHub] ant-ivy issue #73: Enable XML report parser to produce qualified extra attri...
Github user jaikiran commented on the issue: https://github.com/apache/ant-ivy/pull/73 retest this please --- - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
[GitHub] ant-ivy issue #73: Enable XML report parser to produce qualified extra attri...
Github user jaikiran commented on the issue: https://github.com/apache/ant-ivy/pull/73 Tests have passed https://builds.apache.org/job/Ivy-GithubPR/361/ --- - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
[GitHub] ant-ivy issue #73: Enable XML report parser to produce qualified extra attri...
Github user jaikiran commented on the issue: https://github.com/apache/ant-ivy/pull/73 >> By the way, latest commits 43ddccb and 5918182 introduced nested "javaversion" element, which breaks Jenkins CI build; I had to remove this for both I just fixed the PR build to use the latest 1.9.x version of Ant to build the project. --- - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
[GitHub] ant-ivy issue #73: Enable XML report parser to produce qualified extra attri...
Github user jaikiran commented on the issue: https://github.com/apache/ant-ivy/pull/73 retest this please --- - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
[GitHub] ant issue #66: Fixed Spelling.
Github user jaikiran commented on the issue: https://github.com/apache/ant/pull/66 this is ok to test --- - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Jenkins-Builds failing
I would like to test/import a few more projects (that Nicolas mentioned in one the mails) locally into the latest upstream version of the IDE, before starting a release. I have only tested a few so far. -Jaikiran On 28/07/18 2:28 PM, Gintautas Grigelionis wrote: > Thanks, Jaikiran. Would you be willing to restart the release process > for IvyDE now? Gintas On Fri, 27 Jul 2018 at 15:43, Jaikiran Pai > wrote: >> On 25/07/18 6:45 PM, Jaikiran Pai wrote: >>> Almost all jobs that I know of have been taken care of now. There's >>> a "Ivy-tests-Windows" job which is pending, but for that I need some >>> help from infra team. I am discussing it with them separately and I >>> expect it to be resolved soon. I'll fix that job tomorrow. >> This is now done too. -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
Re: Jenkins-Builds failing
On 25/07/18 6:45 PM, Jaikiran Pai wrote: > Almost all jobs that I know of have been taken care of now. There's a > "Ivy-tests-Windows" job which is pending, but for that I need some help > from infra team. I am discussing it with them separately and I expect it > to be resolved soon. I'll fix that job tomorrow. This is now done too. -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Jenkins-Builds failing
Almost all jobs that I know of have been taken care of now. There's a "Ivy-tests-Windows" job which is pending, but for that I need some help from infra team. I am discussing it with them separately and I expect it to be resolved soon. I'll fix that job tomorrow. -Jaikiran On 25/07/18 11:07 AM, Jaikiran Pai wrote: > There are a few more jobs that need to be reconfigured a bit to get them > working. I'm working with infra team to have that sorted out. Please > ignore the failure mails from those jobs for now. > > -Jaikiran > > On 25/07/18 10:30 AM, Jaikiran Pai wrote: >> I've committed a change[1] to handle this in the part where we trigger >> the tutorial run. [1] >> https://github.com/apache/ant-ivy/commit/43ddccb859b94c79350ece7520af4c991c2bb5e6 >> -Jaikiran On 24/07/18 10:53 PM, Gintautas Grigelionis wrote: >>> Thank you for all attempts, the failure occurs in run-tutorial macro >>> (forked JVM). What would be the best way to forwarding Java >>> arguments/system properties? Gintas On Tue, 24 Jul 2018 at 09:14, >>> Gintautas Grigelionis wrote: >>>> It must be set as Java parameter, not Ant parameter. Gintas On Tue, >>>> 24 Jul 2018 at 08:38, Jan Matèrne (jhm) wrote: >>>>> "Looks like someone called 'hibou' restricted the job to >>>>> themselves. (See screenshot attached to this ticket)" This was a >>>>> "run as hibou" configuration. @Nicolas: What was the reason to add >>>>> that? Is it required? Gavin removed that part and I could add the >>>>> https.protocols=TLSv1.2 parameter. Job restarted. Jan >>>>>> -Ursprüngliche Nachricht- Von: Jan Matèrne (jhm) >>>>>> [mailto:apa...@materne.de] Gesendet: Sonntag, 22. Juli 2018 12:54 >>>>>> An: 'Ant Developers List' Betreff: AW: Jenkins-Builds failing >>>>>> Checked by myself that a PMC chair could do (AFAIK). Opened a >>>>>> ticket https://issues.apache.org/jira/browse/INFRA-16799 Jan >>>>>>> -Ursprüngliche Nachricht- Von: Gintautas Grigelionis >>>>>>> [mailto:g.grigelio...@gmail.com] Gesendet: Sonntag, 22. Juli 2018 >>>>>>> 10:48 An: Ant Developers List Betreff: Re: Jenkins-Builds failing >>>>>>> Should we ask infra if nobody else knows about Jenkins >>>>>>> authorization? Gintas On Fri, 20 Jul 2018 at 11:26, Jan Matèrne >>>>>>> (jhm) wrote: >>>>>>>> Neither do I. Jan >>>>>>>>> -Ursprüngliche Nachricht- Von: Jaikiran Pai >>>>>>>>> [mailto:jai.forums2...@gmail.com] Gesendet: Freitag, 20. Juli >>>>>>>>> 2018 10:15 An: dev@ant.apache.org Betreff: Re: Jenkins-Builds >>>>>>>>> failing Now that I checked the job's logs, I think that's true. >>>>>>>>> We had this issue in Ant too (not really against Maven repos, >>>>>>>>> but HTTPS hosted Apache infrastructure). I tried setting that >>>>>>>>> property in the job, but I too don't have the necessary >>>>>>>>> authorization. I >>>>>> don't >>>>>>>>> remember if I ever had those permissions or if it's something >>>>>> that >>>>>>>>> changed with the recent Jenkins upgrade. -Jaikiran On 20/07/18 >>>>>>>>> 1:34 PM, Gintautas Grigelionis wrote: >>>>>>>>>> My hypothesis is that Java 7 must have TLS version forced to >>>>>> 1.2 >>>>>>>>>> in order to avoid protocol errors when downloading new >>>>>>>>>> binaries from Maven Central because earlier versions are >>>>>>>>>> disabled [1] (and TLS 1.0 is the default in Java 7). Gintas 1. >>>>>>>>>> https://blog.pcisecuritystandards.org/are-you-ready-for-30- >>>>>> june- >>>>>>> 20 >>>>>>>>>> 18- >>>>>>>>> s >>>>>>>>>> ayin-goodbye-to-ssl-early-tls On Fri, 20 Jul 2018 at 09:31, >>>>>>>>>> Jaikiran Pai >>>>>>>>> wrote: >>>>>>>>>>> Haven't checked the job, but why is this system property >>>>>>> required >>>>>>>>>>> to be set? -Jaikiran On 20/07/18 12:51 AM, Gintaut
Re: Jenkins-Builds failing
There are a few more jobs that need to be reconfigured a bit to get them working. I'm working with infra team to have that sorted out. Please ignore the failure mails from those jobs for now. -Jaikiran On 25/07/18 10:30 AM, Jaikiran Pai wrote: > I've committed a change[1] to handle this in the part where we trigger > the tutorial run. [1] > https://github.com/apache/ant-ivy/commit/43ddccb859b94c79350ece7520af4c991c2bb5e6 > -Jaikiran On 24/07/18 10:53 PM, Gintautas Grigelionis wrote: >> Thank you for all attempts, the failure occurs in run-tutorial macro >> (forked JVM). What would be the best way to forwarding Java >> arguments/system properties? Gintas On Tue, 24 Jul 2018 at 09:14, >> Gintautas Grigelionis wrote: >>> It must be set as Java parameter, not Ant parameter. Gintas On Tue, >>> 24 Jul 2018 at 08:38, Jan Matèrne (jhm) wrote: >>>> "Looks like someone called 'hibou' restricted the job to >>>> themselves. (See screenshot attached to this ticket)" This was a >>>> "run as hibou" configuration. @Nicolas: What was the reason to add >>>> that? Is it required? Gavin removed that part and I could add the >>>> https.protocols=TLSv1.2 parameter. Job restarted. Jan >>>>> -Ursprüngliche Nachricht- Von: Jan Matèrne (jhm) >>>>> [mailto:apa...@materne.de] Gesendet: Sonntag, 22. Juli 2018 12:54 >>>>> An: 'Ant Developers List' Betreff: AW: Jenkins-Builds failing >>>>> Checked by myself that a PMC chair could do (AFAIK). Opened a >>>>> ticket https://issues.apache.org/jira/browse/INFRA-16799 Jan >>>>>> -Ursprüngliche Nachricht- Von: Gintautas Grigelionis >>>>>> [mailto:g.grigelio...@gmail.com] Gesendet: Sonntag, 22. Juli 2018 >>>>>> 10:48 An: Ant Developers List Betreff: Re: Jenkins-Builds failing >>>>>> Should we ask infra if nobody else knows about Jenkins >>>>>> authorization? Gintas On Fri, 20 Jul 2018 at 11:26, Jan Matèrne >>>>>> (jhm) wrote: >>>>>>> Neither do I. Jan >>>>>>>> -Ursprüngliche Nachricht- Von: Jaikiran Pai >>>>>>>> [mailto:jai.forums2...@gmail.com] Gesendet: Freitag, 20. Juli >>>>>>>> 2018 10:15 An: dev@ant.apache.org Betreff: Re: Jenkins-Builds >>>>>>>> failing Now that I checked the job's logs, I think that's true. >>>>>>>> We had this issue in Ant too (not really against Maven repos, >>>>>>>> but HTTPS hosted Apache infrastructure). I tried setting that >>>>>>>> property in the job, but I too don't have the necessary >>>>>>>> authorization. I >>>>> don't >>>>>>>> remember if I ever had those permissions or if it's something >>>>> that >>>>>>>> changed with the recent Jenkins upgrade. -Jaikiran On 20/07/18 >>>>>>>> 1:34 PM, Gintautas Grigelionis wrote: >>>>>>>>> My hypothesis is that Java 7 must have TLS version forced to >>>>> 1.2 >>>>>>>>> in order to avoid protocol errors when downloading new >>>>>>>>> binaries from Maven Central because earlier versions are >>>>>>>>> disabled [1] (and TLS 1.0 is the default in Java 7). Gintas 1. >>>>>>>>> https://blog.pcisecuritystandards.org/are-you-ready-for-30- >>>>> june- >>>>>> 20 >>>>>>>>> 18- >>>>>>>> s >>>>>>>>> ayin-goodbye-to-ssl-early-tls On Fri, 20 Jul 2018 at 09:31, >>>>>>>>> Jaikiran Pai >>>>>>>> wrote: >>>>>>>>>> Haven't checked the job, but why is this system property >>>>>> required >>>>>>>>>> to be set? -Jaikiran On 20/07/18 12:51 AM, Gintautas >>>>>>>>>> Grigelionis wrote: >>>>>>>>>>> I'd like to add a Java option to Ivy builds >>>>>>>>>>> -Dhttps.protocols=TLSv1.2 >>>>>>>>>> but I >>>>>>>>>>> get This job's current authorization strategy does not permit >>>>>> gintas >>>>>>>>>>> to >>>>>>>>>> modify >>>>>>>>>>> the job configuration Gintas On Tue, 3 Jul 20
Re: Jenkins-Builds failing
I've committed a change[1] to handle this in the part where we trigger the tutorial run. [1] https://github.com/apache/ant-ivy/commit/43ddccb859b94c79350ece7520af4c991c2bb5e6 -Jaikiran On 24/07/18 10:53 PM, Gintautas Grigelionis wrote: > Thank you for all attempts, the failure occurs in run-tutorial macro > (forked JVM). > What would be the best way to forwarding Java arguments/system properties? > > Gintas > > On Tue, 24 Jul 2018 at 09:14, Gintautas Grigelionis > wrote: > >> It must be set as Java parameter, not Ant parameter. >> >> Gintas >> >> On Tue, 24 Jul 2018 at 08:38, Jan Matèrne (jhm) wrote: >> >>> "Looks like someone called 'hibou' restricted the job to themselves. (See >>> screenshot attached to this ticket)" >>> >>> This was a "run as hibou" configuration. >>> >>> @Nicolas: What was the reason to add that? Is it required? >>> >>> >>> Gavin removed that part and I could add the https.protocols=TLSv1.2 >>> parameter. >>> Job restarted. >>> >>> >>> Jan >>> >>> >>>> -Ursprüngliche Nachricht- >>>> Von: Jan Matèrne (jhm) [mailto:apa...@materne.de] >>>> Gesendet: Sonntag, 22. Juli 2018 12:54 >>>> An: 'Ant Developers List' >>>> Betreff: AW: Jenkins-Builds failing >>>> >>>> Checked by myself that a PMC chair could do (AFAIK). >>>> Opened a ticket >>>> https://issues.apache.org/jira/browse/INFRA-16799 >>>> >>>> Jan >>>> >>>>> -Ursprüngliche Nachricht- >>>>> Von: Gintautas Grigelionis [mailto:g.grigelio...@gmail.com] >>>>> Gesendet: Sonntag, 22. Juli 2018 10:48 >>>>> An: Ant Developers List >>>>> Betreff: Re: Jenkins-Builds failing >>>>> >>>>> Should we ask infra if nobody else knows about Jenkins authorization? >>>>> >>>>> Gintas >>>>> >>>>> On Fri, 20 Jul 2018 at 11:26, Jan Matèrne (jhm) >>>>> wrote: >>>>> >>>>>> Neither do I. >>>>>> >>>>>> Jan >>>>>> >>>>>>> -Ursprüngliche Nachricht- >>>>>>> Von: Jaikiran Pai [mailto:jai.forums2...@gmail.com] >>>>>>> Gesendet: Freitag, 20. Juli 2018 10:15 >>>>>>> An: dev@ant.apache.org >>>>>>> Betreff: Re: Jenkins-Builds failing >>>>>>> >>>>>>> Now that I checked the job's logs, I think that's true. We had >>>>>>> this issue in Ant too (not really against Maven repos, but HTTPS >>>>>>> hosted Apache infrastructure). I tried setting that property in >>>>>>> the job, but I too don't have the necessary authorization. I >>>> don't >>>>>>> remember if I ever had those permissions or if it's something >>>> that >>>>>>> changed with the recent Jenkins upgrade. >>>>>>> >>>>>>> -Jaikiran >>>>>>> >>>>>>> >>>>>>> On 20/07/18 1:34 PM, Gintautas Grigelionis wrote: >>>>>>>> My hypothesis is that Java 7 must have TLS version forced to >>>> 1.2 >>>>>>>> in order to avoid protocol errors when downloading new binaries >>>>>>>> from Maven Central because earlier versions are disabled [1] >>>>>>>> (and TLS 1.0 is the default in Java 7). >>>>>>>> >>>>>>>> Gintas >>>>>>>> >>>>>>>> 1. >>>>>>>> https://blog.pcisecuritystandards.org/are-you-ready-for-30- >>>> june- >>>>> 20 >>>>>>>> 18- >>>>>>> s >>>>>>>> ayin-goodbye-to-ssl-early-tls >>>>>>>> >>>>>>>> On Fri, 20 Jul 2018 at 09:31, Jaikiran Pai >>>>>>>> >>>>>>> wrote: >>>>>>>>> Haven't checked the job, but why is this system property >>>>> required >>>>>>>>> to be set? >>>>>>>>> >>>>>>>>> -Jaikiran >>>>>>>>> >>>>>>>>> >>>>>>>>> On
Re: Jenkins-Builds failing
Now that I checked the job's logs, I think that's true. We had this issue in Ant too (not really against Maven repos, but HTTPS hosted Apache infrastructure). I tried setting that property in the job, but I too don't have the necessary authorization. I don't remember if I ever had those permissions or if it's something that changed with the recent Jenkins upgrade. -Jaikiran On 20/07/18 1:34 PM, Gintautas Grigelionis wrote: > My hypothesis is that Java 7 must have TLS version forced to 1.2 in order > to avoid protocol errors when downloading new binaries from Maven Central > because earlier versions are disabled [1] (and TLS 1.0 is the default in > Java 7). > > Gintas > > 1. > https://blog.pcisecuritystandards.org/are-you-ready-for-30-june-2018-sayin-goodbye-to-ssl-early-tls > > On Fri, 20 Jul 2018 at 09:31, Jaikiran Pai wrote: > >> Haven't checked the job, but why is this system property required to be >> set? >> >> -Jaikiran >> >> >> On 20/07/18 12:51 AM, Gintautas Grigelionis wrote: >>> I'd like to add a Java option to Ivy builds -Dhttps.protocols=TLSv1.2 >> but I >>> get >>> This job's current authorization strategy does not permit gintas to >> modify >>> the job configuration >>> >>> Gintas >>> >>> On Tue, 3 Jul 2018 at 19:09, Gintautas Grigelionis < >> g.grigelio...@gmail.com> >>> wrote: >>> >>>> Ant nightly is stuck on archiving for 30 hours now. >>>> It should be escalated, I believe that could have something to do with >> the >>>> last upgrade of Jenkins. >>>> >>>> Gintas >>>> >>>> On Mon, 2 Jul 2018 at 14:18, Jan Matèrne wrote: >>>> >>>>> Several of our Jenkins builds are failing: >>>>> >>>>> >>>>> >>>>> IvyDE: >>>>> >>>>> https://builds.apache.org/view/A/view/Ant/job/IvyDE/ >>>>> >>>>> https://builds.apache.org/view/A/view/Ant/job/IvyDE/lastBuild/console >>>>> >>>>> Can't get >>>>> >>>>> >> http://download.eclipse.org/webtools/downloads/drops/R3.4.2/R-3.4.2-20130208 >>>>> 151217/wtp4x-R-3.4.2-20130208151217.zip >>>>> < >> http://download.eclipse.org/webtools/downloads/drops/R3.4.2/R-3.4.2-20130208151217/wtp4x-R-3.4.2-20130208151217.zip >>>>> to >>>>> >>>>> >> /home/jenkins/jenkins-slave/workspace/IvyDE/dependencies/wtp4x-R-3.4.2-20130 >>>>> 208151217.zip >>>>> >>>>> >>>>> >>>>> The source URL gives a 404. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> AntLib - AntUnit >>>>> >>>>> https://builds.apache.org/view/A/view/Ant/job/AntLib-antunit/ >>>>> >>>>> >>>>> >> https://builds.apache.org/view/A/view/Ant/job/AntLib-antunit/lastBuild/conso >>>>> le >>>>> >>>>> [ivy:resolve] Server access error at url >>>>> >>>>> >> https://repo1.maven.org/maven2/org/apache/ant/ant-testutil/1.8.1/ant-testuti >>>>> l-1.8.1.pom >>>>> < >> https://repo1.maven.org/maven2/org/apache/ant/ant-testutil/1.8.1/ant-testutil-1.8.1.pom >>>>> (javax.net.ssl.SSLException: Received fatal alert: >>>>> protocol_version) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> AntLib - SVN >>>>> >>>>> same problem as for AU >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Ivy >>>>> >>>>> https://builds.apache.org/view/A/view/Ant/job/Ivy/ >>>>> >>>>> https://builds.apache.org/view/A/view/Ant/job/Ivy/lastBuild/console >>>>> >>>>> same problem as for AU >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Ant Nightly >>>>> >>>>> https://builds.apache.org/view/A/view/Ant/job/Ant_Nightly/ >>>>> >>>>> >>>>> >> https://builds.apache.org/view/A/view/Ant/job/Ant_Nightly/lastBuild/console >>>>> all runs fine, but "Archiving artifacts" requires lt of time … >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Ideas? >>>>> >>>>> >>>>> >>>>> Jan >>>>> >>>>> >> >> - >> 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
Re: Jenkins-Builds failing
Haven't checked the job, but why is this system property required to be set? -Jaikiran On 20/07/18 12:51 AM, Gintautas Grigelionis wrote: > I'd like to add a Java option to Ivy builds -Dhttps.protocols=TLSv1.2 but I > get > This job's current authorization strategy does not permit gintas to modify > the job configuration > > Gintas > > On Tue, 3 Jul 2018 at 19:09, Gintautas Grigelionis > wrote: > >> Ant nightly is stuck on archiving for 30 hours now. >> It should be escalated, I believe that could have something to do with the >> last upgrade of Jenkins. >> >> Gintas >> >> On Mon, 2 Jul 2018 at 14:18, Jan Matèrne wrote: >> >>> Several of our Jenkins builds are failing: >>> >>> >>> >>> IvyDE: >>> >>> https://builds.apache.org/view/A/view/Ant/job/IvyDE/ >>> >>> https://builds.apache.org/view/A/view/Ant/job/IvyDE/lastBuild/console >>> >>> Can't get >>> >>> http://download.eclipse.org/webtools/downloads/drops/R3.4.2/R-3.4.2-20130208 >>> 151217/wtp4x-R-3.4.2-20130208151217.zip >>> <http://download.eclipse.org/webtools/downloads/drops/R3.4.2/R-3.4.2-20130208151217/wtp4x-R-3.4.2-20130208151217.zip> >>> to >>> >>> /home/jenkins/jenkins-slave/workspace/IvyDE/dependencies/wtp4x-R-3.4.2-20130 >>> 208151217.zip >>> >>> >>> >>> The source URL gives a 404. >>> >>> >>> >>> >>> >>> AntLib - AntUnit >>> >>> https://builds.apache.org/view/A/view/Ant/job/AntLib-antunit/ >>> >>> >>> https://builds.apache.org/view/A/view/Ant/job/AntLib-antunit/lastBuild/conso >>> le >>> >>> [ivy:resolve] Server access error at url >>> >>> https://repo1.maven.org/maven2/org/apache/ant/ant-testutil/1.8.1/ant-testuti >>> l-1.8.1.pom >>> <https://repo1.maven.org/maven2/org/apache/ant/ant-testutil/1.8.1/ant-testutil-1.8.1.pom> >>> (javax.net.ssl.SSLException: Received fatal alert: >>> protocol_version) >>> >>> >>> >>> >>> >>> AntLib - SVN >>> >>> same problem as for AU >>> >>> >>> >>> >>> >>> Ivy >>> >>> https://builds.apache.org/view/A/view/Ant/job/Ivy/ >>> >>> https://builds.apache.org/view/A/view/Ant/job/Ivy/lastBuild/console >>> >>> same problem as for AU >>> >>> >>> >>> >>> >>> Ant Nightly >>> >>> https://builds.apache.org/view/A/view/Ant/job/Ant_Nightly/ >>> >>> >>> https://builds.apache.org/view/A/view/Ant/job/Ant_Nightly/lastBuild/console >>> >>> all runs fine, but "Archiving artifacts" requires lt of time … >>> >>> >>> >>> >>> >>> Ideas? >>> >>> >>> >>> Jan >>> >>> - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
[GitHub] ant issue #65: Update manual for subject alternative name attribute of genke...
Github user jaikiran commented on the issue: https://github.com/apache/ant/pull/65 I picked the commit which updated just the documentation and merged it to upstream. --- - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
[GitHub] ant issue #64: Add support for SAN extension in GenerateKey task
Github user jaikiran commented on the issue: https://github.com/apache/ant/pull/64 @jnsnkrllive I've merged this into 1.9.x as well as master branches. Thank you for the PR. I've also included your name "Karl Jansen" in our contributors list. If you like to use a different name, let us know. Finally, would you be interested in the updating the manual of the generatekey task to make a mention of this new attribute and send a new PR? If not, I'll get to it later in the week myself. --- - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
[ANNOUNCE] Apache Ant 1.9.13 and 1.10.5 Released
The Apache Ant Team is pleased to announce the releases of Apache Ant 1.9.13 and 1.10.5. The Apache Ant team currently maintains two lines of development. The 1.9.x releases require Java5 at runtime and 1.10.x requires Java8 at runtime. Both lines are based off of Ant 1.9.7 and the 1.9.x releases are mostly bug fix releases while additional new features are developed for 1.10.x. We recommend using 1.10.5 unless you are required to use versions of Java prior to Java8 during the build process. Ant 1.10.5 contains a superset of 1.9.13 - with the exception of a few tasks and features that no longer work with Java8 anyway (like the apt task). Both releases are mostly bug fix releases with few new features added. Both 1.9.13 and 1.10.5 fix a regression in the "get" task and also address a remaining issue with unjar, untar and unzip tasks where they would end up extracting content outside of the destination directory. 1.10.5 also introduces an enhancement to the "java" task to allow launching single-file source programs, a Java language feature that is introduced in the upcoming Java 11 release. Source and binary distributions are available for download from the Apache Ant download site: https://ant.apache.org/bindownload.cgi https://ant.apache.org/srcdownload.cgi When downloading, please verify signatures by following the instructions noted in the "Verify Releases" section at the above locations. Changes in 1.10.5 include: == Fixed bugs: --- * Fixes a regression in the "get" task where redirects from a HTTP resource to a HTTPS resource started throwing an exception. Bugzilla Report 62499 * the new allowFilesToEscapeDest didn't work when set to false and archive entries contained relative paths with so many ".." segnments that the resulting path would go beyond the file system root. Bugzilla Report 62502 Other changes: -- * Java task now accepts a "sourcefile" attribute to allow single file source program execution, a feature that is introduced in Java 11. Changes in 1.9.13 include: == Fixed bugs: --- * Fixes a regression in the "get" task where redirects from a HTTP resource to a HTTPS resource started throwing an exception. Bugzilla Report 62499 * the new allowFilesToEscapeDest didn't work when set to false and archive entries contained relative paths with so many ".." segnments that the resulting path would go beyond the file system root. Bugzilla Report 62502 For complete information on Ant, including instructions on how to submit bug reports, patches, or suggestions for improvement, see the Apache Ant website https://ant.apache.org/ -Jaikiran Pai, on behalf of the Apache Ant community signature.asc Description: OpenPGP digital signature
[GitHub] ant issue #64: Add support for SAN extension in GenerateKey task
Github user jaikiran commented on the issue: https://github.com/apache/ant/pull/64 Thank you @jnsnkrllive. This now looks fine to me. I'll merge this later tonight/tomorrow, once our currently in-progress Ant release(s) are officially announced. --- - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
[GitHub] ant pull request #64: Add support for SAN extension in GenerateKey task
Github user jaikiran commented on a diff in the pull request:
https://github.com/apache/ant/pull/64#discussion_r202287386
--- Diff: src/main/org/apache/tools/ant/taskdefs/GenerateKey.java ---
@@ -413,6 +429,16 @@ public void execute() throws BuildException {
sb.append("\" ");
}
+if (useExtension) {
+sb.append("-ext ");
--- End diff --
>> However, we won't ever append "-ext" without also appending a name too.
Currently the only way to append "-ext" is when useExtension is true, which
only happens if the sname attribute is included in the definition AND the java
version is 1.7 or higher.
Hi @jnsnkrllive, The reason I brought it up is because I see that the `san`
extension name gets added only if the `saname` is set to non-null. Whereas the
`ext` argument gets passed whether or not `saname` is null because the
`useExtension` gets set to `true` irrespective of whether or not the saname is
null (imagine someone calling setSaname with a null value). Perhaps, we don't
need "useExtension" field for now (until we introduce more supported extension
names)? That way you can add the "-ext -san=" if there's non-null
`saname` set?
---
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
[GitHub] ant pull request #64: Add support for SAN extension in GenerateKey task
Github user jaikiran commented on a diff in the pull request:
https://github.com/apache/ant/pull/64#discussion_r202054728
--- Diff: src/main/org/apache/tools/ant/taskdefs/GenerateKey.java ---
@@ -413,6 +429,16 @@ public void execute() throws BuildException {
sb.append("\" ");
}
+if (useExtension) {
+sb.append("-ext ");
--- End diff --
Should this be appended only if `saname` is not null? I haven't given it a
try but does the keytool work fine if we end up passing "-ext" without any
extension name value?
---
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
[GitHub] ant issue #64: Add support for SAN extension in GenerateKey task
Github user jaikiran commented on the issue: https://github.com/apache/ant/pull/64 this is ok to test --- - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [VOTE] Release Ant 1.10.5 based on RC1
+1
- Downloaded the .tar.gz from https://dist.apache.org/repos/dist/dev/ant/
- Extracted locally
- Checked the NOTICE and WHATSNEW files. Looks fine.
- Checked some random manuals. Looks fine.
- Checked the javac task manual. Looks fine.
- Tested the following build script to verify that it fails with a
previous version of 1.10.x and now passes in 1.10.5:
src="http://downloads.sourceforge.net/easymock/easymock-3.2.zip";
dest="${basedir}/downloaded/"/>
- Tested the following build script to verify that the new "sourcefile"
feature of Java task works:
A.java:
public class A {
public static void main(final String[] args) throws Exception {
System.out.println("Hello Ant 1.10.5!");
}
}
Worked fine.
-Jaikiran
On 10/07/18 3:25 PM, Stefan Bodewig wrote:
Hi all
I've created a new release candidate for 1.10.5 with a few bug fixes and
and the "single source executable" feature for Java11.
git tag: ANT_1.10.5_RC1
on commit: c0848d2c6
tarballs: https://dist.apache.org/repos/dist/dev/ant/
revision: 28015
Maven artifacts:
https://repository.apache.org/content/repositories/orgapacheant-1035/org/apache/ant/
This Vote will be open at least for 72 hours and close no earlier than
2018-07-13 10:00UTC.
Cheers
Stefan
-
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
Re: [VOTE] Release Ant 1.9.13 based on RC1
+1
- Downloaded .tar.gz from
https://dist.apache.org/repos/dist/dev/ant/binaries/
- Extracted locally, checked WHATSNEW, NOTICE files.
- Browsed some random manual pages. Looks fine.
- Built some internal Ant based projects. All went fine.
- Tested that the following build script works with this new version
(and fails with previous 1.9.x released version) to verify the
https://bz.apache.org/bugzilla/show_bug.cgi?id=62164 issue:
src="http://downloads.sourceforge.net/easymock/easymock-3.2.zip";
dest="${basedir}/downloaded/"/>
-Jaikiran
On 10/07/18 3:26 PM, Stefan Bodewig wrote:
Hi all
I've created a new release candidate for 1.9.13 with a few bug fixes.
git tag: ANT_1.9.13_RC1
on commit: e7a4d8683
tarballs: https://dist.apache.org/repos/dist/dev/ant/
revision: 28014
Maven artifacts:
https://repository.apache.org/content/repositories/orgapacheant-1034/org/apache/ant/
This Vote will be open at least for 72 hours and close no earlier than
2018-07-13 10:00UTC.
Cheers
Stefan
-
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
Re: ant git commit: Unbreak tests
Hello Martijn,
Thank you for spending time on this and for that checker. I did look
into yourmail and considered itbefore deciding on what to do with the
state of upstream branches.I decided to go with a complete revert
approach (which I explain in a separate reply in this thread), because I
personally felt a lot more confident in what it meant and involved, in
terms of git technicalities.
Again, thank you very much for these efforts. Just like you and everyone
else who's been involved in the project, I am not happy that we had to
do a revertand the sequence of eventswhich led us to this.
-Jaikiran
On 06/07/18 5:19 PM, j...@apache.org wrote:
Hello all
Just for your info, please take into consideration for a rollback or
not descision (I am neither happy with the commit, nor happy with a
rollback and therefore am 0 on rollback or not):
I have written a small checker to remove all whitespace only diffs
from the diffs on the URL below.
Significant whitespace changes that may have been lost would be
unlikely (space difference before "/>" , ">" or ")" and around "=" is
also ignored)
That would reduce the original "2f64e0b5" diff to (the extra lines
starting with \ before the diff are added by the checker i wrote)
Removing whitespace only changes from asf.txt
From: Gintas Grigelionis
Date: Sun, 1 Jul 2018 13:31:35 + (+0200)
Subject: Trailing whitespace
X-Git-Url:
https://git1-us-west.apache.org/repos/asf?p=ant.git;a=commitdiff_plain;h=2f64e0b5
Trailing whitespace
---
\
\@ -87,11 +87,11 @@
JDepend Analysis align="right">Designed for use with href="http://www.clarkware.com/software/JDepend.html";>JDepend and
https://ant.apache.org";>Ant. width="100%"> Summary
\@ -87,11 +87,11 @@
JDepend Analysis align="right">Designed for use with href="http://www.clarkware.com/software/JDepend.html";>JDepend and
http://jakarta.apache.org";>Ant. width="100%"> Summary
\
diff --git a/src/etc/jdepend.xsl b/src/etc/jdepend.xsl
index f813297..907ade2 100644
--- a/src/etc/jdepend.xsl
+++ b/src/etc/jdepend.xsl
@@ -87,11 +87,11 @@
-
+
JDepend Analysis
- Designed for use with href="http://www.clarkware.com/software/JDepend.html";>JDepend and
http://jakarta.apache.org";>Ant.
-
-
+ Designed for use with href="http://www.clarkware.com/software/JDepend.html";>JDepend and
https://ant.apache.org";>Ant.
+
+
Summary
\
\@ -57,8 +57,8 @@ dir="${test.dir}/src/org/apache/tools/ant"/> dir="${test.dir}/dest"/> file="${test.dir}/src/org/apache/tools/ant/DirscannerSetup.java">
Re: ant git commit: Unbreak tests
; branch of upstream repo. At this point, these branches are in a state where they can be used for regular development and other planned activities. -Jaikiran On 06/07/18 2:32 PM, Stefan Bodewig wrote: On 2018-07-06, Jaikiran Pai wrote: On 05/07/18 2:42 PM, Stefan Bodewig wrote: On 2018-07-05, Jaikiran Pai wrote: I personally believe that reviewing these meaningless changes is a waste of time and energy. I'm in favour of rolling back the entire commit set if that's what it takes. +1 although reverting the commits in both branches and merging back the 1.9.x branch is likely going to end in an ugly merge that will need review as well. Hopefullly a shorter one. Yes, I agree.I plan to attempt this later tonight (around 8 hours from now) if no one else gets to it before that. Just letting it know here, so that we don't end up duplicating these efforts. Thank you. I'm unlikely to get there before you do, would have tackled it tomorrow. Stefan - 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
Re: ant git commit: Unbreak tests
On 05/07/18 2:42 PM, Stefan Bodewig wrote: On 2018-07-05, Jaikiran Pai wrote: I personally believe that reviewing these meaningless changes is a waste of time and energy. I'm in favour of rolling back the entire commit set if that's what it takes. +1 although reverting the commits in both branches and merging back the 1.9.x branch is likely going to end in an ugly merge that will need review as well. Hopefullly a shorter one. Yes, I agree.I plan to attempt this later tonight (around 8 hours from now) if no one else gets to it before that. Just letting it know here, so that we don't end up duplicating these efforts. -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: ant git commit: Enhance the Java task to allow single file source program execution, a feature, introduced in Java 11
On 05/07/18 1:02 AM, Stefan Bodewig wrote: On 2018-07-04, wrote: Enhance the Java task to allow single file source program execution, a feature, introduced in Java 11 +1 Could you please add javadocs to the new getter/setter in CommmandLineJava? Ah yes, missed that one. Added now. -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: ant git commit: Unbreak tests
On 05/07/18 12:57 AM, Stefan Bodewig wrote: Gintas, - passfile="testpassfile.tmp"%/> + passfile="testpassfile.tmp"/> the commit that introduced the issue was labeled "Trailing whitespace" and I trusted to contain exactly that and didn't bother reviewing it. Obviously it did not. A single commit that spans a dozen mail messages is something you really cannot review properly. Glitches happen, this is not a problem. But if they hide inside a patch that contains more than 4500 changes lines it becomes impossible to deal with them. Given we were planning to cut new releases I now feel very uncomfortable and compelled to wade through all those 4500 lines as well as the 4500 lines of the other commit with the same message and the merge of the 1.9 branch (and doing the same to the equally big commits on the 1.9.x branch). This is going to delay the releases by several days, at least. It was made explicitly clear by committers, PMC members and Ant PMC chairman that the commits of these nature aren't acceptable. Yet, more and more such commits have been done over and over again, using these upstream repos as a personal playground and forcing it on the rest of the community. At this point, I personally believe that reviewing these meaningless changes is a waste of time and energy. I'm in favour of rolling back the entire commit set if that's what it takes. -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Testing IvyDE
On 01/07/18 6:35 PM, Nicolas Lalevée wrote: Le 28 juin 2018 à 08:41, Jaikiran Pai a écrit : On 27/06/18 10:12 PM, Nicolas Lalevée wrote: Since there is a work around (hitting refresh after resolve) and it is an RC, we could ship it like that and fix it later. But due to the automatic update via the update site, I bet most users will update even if it is an RC. So I am not sure what I should vote. So I vote -0 for me for now. I was reserving my vote just for this reason. I don't use Eclipse so I wanted to see if someone more familiar with it has an opinion about this bug. You are right that it's going to end up affecting everyone once we release this. Given that the purpose of this release is revive this project a bit and not break setups where things are working fine and the fact that this will end up being an annoying kind of workaround (having to hit refresh after resolve), I don't see rushing this release without fixing this issue serves any purpose. So I'll vote a -1 on this now. I know we have gone through 3 voting rounds for this release, so thank you everyone for being patient and testing out the binaries. I'll file this issue in JIRA and hopefully spend some time in Eclipse this weekend to try and sort this out. I have found the issue and pushed a fix. Thank you. I am then worried that the master is not well tested nor used after the big cleanups. Yes, I agree. So I suggest we do a little testing now of the master. To help with that, there is a folder in the IvyDE project which contains projects ready to be imported into Eclipse, they are samples of many different configurations which should be supported I'll test some of these out during the week. -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: FileUtils.normalize/isLeadingPath have bitten me
Hi Stefan, I did some testing manually for this new method, with both symlinks and non-symlinks with both the string check version and the getParent() version. In both of those, I couldn't get it to break in any odd ways (which is a good thing). It also means that my theory that the string comparison may not always be a best idea is just theoretical. However, I just feel a bit more comfortable seeing the getParent() version since that then removes any kind of file separator or odd backslash/frontslash permutations that we may not have thought of and instead leaves it to the JRE implementation to deal with it. Again, this is me being a bit paranoid than any real demoable issue with the string comparison code. So thank you for using the getParent() call in this implementation. At this point, I think these commits address the issue that we sought out to fix. So unless someone else sees any issues, I think we can go ahead and do the release that you had planned for. -Jaikiran On 03/07/18 1:16 PM, Stefan Bodewig wrote: On 2018-07-02, Stefan Bodewig wrote: On 2018-07-02, Jaikiran Pai wrote: I just checked the commits related to this and it looks mostly correct. However, I am still not 100% sure we have covered it all with this new method that was introduced[1] and used in the unzip part. What I mean is, the API expectations are right. However the implementation _might_ need a bit of rethink since it still relies on path string comparison (checks like endsWith) instead of a getParent() check. I mostly kept the string comparison for performance reasons, but maybe that point is moot and performance should not be a concern here. Rewriting it to use getParent is no problem at all. Done Stefan - 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
Re: FileUtils.normalize/isLeadingPath have bitten me
Hi Stefan, Sorry that I couldn't get to this earlier. My plan to spend more time on this during the weekend didn't work out. I just checked the commits related to this and it looks mostly correct. However, I am still not 100% sure we have covered it all with this new method that was introduced[1] and used in the unzip part. What I mean is, the API expectations are right. However the implementation _might_ need a bit of rethink since it still relies on path string comparison (checks like endsWith) instead of a getParent() check. My suspicion is all theoretical at the moment and may not even be valid. I'm going to build the latest changes of Ant give it a try against a bunch of my theoretical use cases and see if my suspicions are really valid or not. [1] https://github.com/apache/ant/commit/6a41d62cb9ab4e640b72cb4de42a6c211dea645d -Jaikiran On 01/07/18 2:57 PM, Stefan Bodewig wrote: On 2018-06-28, Stefan Bodewig wrote: On 2018-06-28, Jaikiran Pai wrote: Which then makes me wonder - in the context of this specific untar/expand/unzip issue, should we probably be using a different custom very specific logic (which relies on canonical files and getParent()) instead of a call to isLeadingPath()? Probably. I used isLeadingPath because it has been already there - and ) simply didn't realize it wouldn't do what I expected it to. I decided to "fix" isLeadingPath for this edge case and add a method using canonical paths instead - and use that in unzip and friends. Please have a look at the proposed solution, I won't close the Bugzilla issue before we have agreed this is the proper fix. Cheers Stefan - 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
Re: FileUtils.normalize/isLeadingPath have bitten me
On 28/06/18 8:37 PM, Stefan Bodewig wrote:
On 2018-06-28, Jaikiran Pai wrote:
However, looking at the FileUtils#isLeadingPath(...) implementation, I
wonder why it even uses normalize. Given that the goal of that API (as
stated in the javadoc) is to figure out if one path leads the other,
to me that translates to being a check to see whether the "leading"
param to that method is a parent of the "path". I suppose that can be
implemented by using the java.io.File#getCanonicalFile() call on each
of the params and then doing a iterative getParent() call on the
canonical File returned for the "path" and seeing if it ends up
leading to the canonical File returned for "leading". The call to
java.io.File#getCanonicalFile() should take care of the ".", ".." and
even symbolic link reference resolutions (which I guess is a good
thing?).
I think I have written that method long ago so I should be able to
answer that. Unfortunately I'm not.
In may cases we did not want to resolve canonical paths. I think the
expectation is that for
/dir
/dir2
/dir3
link -> /dir/dir2
isLeadingPath("/dir/dir3", "/dir/dir3/link") returns true which it would
not do if links have been resolved.
That's a good example and yes it would return false if we would change
it to use canonical paths.
Which then makes me wonder - in the context of this specific
untar/expand/unzip issue, should we probably be using a different custom
very specific logic (which relies on canonical files and getParent())
instead of a call to isLeadingPath()? I don't have an answer though and
I will have to sleep over this a bit to see if it has other implications
and if it does indeed solve the issue at hand.
-Jaikiran
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
Re: FileUtils.normalize/isLeadingPath have bitten me
I don't have enough background on the expectations of the normalize
method, so can't really say how it should behave. Plus, it gets used in
relatively larger number of places as compared to isLeadingPath, so not
too sure how it might impact other places if we do change its existing
semantics.
However, looking at the FileUtils#isLeadingPath(...) implementation, I
wonder why it even uses normalize. Given that the goal of that API (as
stated in the javadoc) is to figure out if one path leads the other, to
me that translates to being a check to see whether the "leading" param
to that method is a parent of the "path". I suppose that can be
implemented by using the java.io.File#getCanonicalFile() call on each of
the params and then doing a iterative getParent() call on the canonical
File returned for the "path" and seeing if it ends up leading to the
canonical File returned for "leading". The call to
java.io.File#getCanonicalFile() should take care of the ".", ".." and
even symbolic link reference resolutions (which I guess is a good
thing?). Do you think this has merits? Or is the expectation of the
isLeadingPath API solely based on the names of that passed files rather
than their actual resolved location on the filesystem? I haven't yet
tried it out myself to have a more clearer understanding of how it will
end up behaving in the context that we use this API.
-Jaikiran
On 28/06/18 7:17 PM, Stefan Bodewig wrote:
Hi all
while looking into https://bz.apache.org/bugzilla/show_bug.cgi?id=62502
I realized that I had a false expectation of what normalize would do in
a certain edge case.
If you feed into it a path with more "../" segments than can be
travelled up, like
FileUtils.normalize("/tmp/dest/../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../Temp/evil.txt")
it will realize it would go outside of the file system root and returns
a new File instance with the original path. I'm not sure what I had
expected (an exception maybe) but this is now what I had assumed, my
fault.
Then isLeadingPath calls normalize for both its arguments and ends up
seeing "/tmp/dest/" is a prefix of
"/tmp/dest/../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../Temp/evil.txt"
and unzip allows the file to escape.
It seems to depend on the OS what it makes of the path, on Linux I
receive an exception but apparently Windows just swallows the excess ../
segments.
I'm not 100% sure how to fix this properly.
Is normalize doing the right thing? If so, we need to fix isLeadingPath
for example by simply always returning false if either normalized path
contains "../" segments (because that means the path cannot exist on
disk at all).
Or should the behavior of normalize change? This unit test snippet
assertEquals("will not go outside FS root (but will not throw an exception
either)",
new File(localize("/1/../../b")),
FILE_UTILS.normalize(localize("/1/../../b")));
makes me think we better leave it as is as it seems to be by design (and
I just have forgotten about it).
In either case, once we agree on the fix I propose to cut new releases
immediately.
Stefan
-
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
[CANCELLED]Re: [VOTE] Release 2.3.0-rc1 of Apache IvyDE
This vote is now officially cancelledfor the reasons noted below. -Jaikiran On 28/06/18 12:11 PM, Jaikiran Pai wrote: On 27/06/18 10:12 PM, Nicolas Lalevée wrote: Since there is a work around (hitting refresh after resolve) and it is an RC, we could ship it like that and fix it later. But due to the automatic update via the update site, I bet most users will update even if it is an RC. So I am not sure what I should vote. So I vote -0 for me for now. I was reserving my vote just for this reason. I don't use Eclipse so I wanted to see if someone more familiar with it has an opinion about this bug. You are right that it's going to end up affecting everyone once we release this. Given that the purpose of this release is revive this project a bit and not break setups where things are working fine and the fact that this will end up being an annoying kind of workaround (having to hit refresh after resolve), I don't see rushing this release without fixing this issue serves any purpose. So I'll vote a -1 on this now. I know we have gone through 3 voting rounds for this release, so thank you everyone for being patient and testing out the binaries. I'll file this issue in JIRA and hopefully spend some time in Eclipse this weekend to try and sort this out. -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [VOTE] Release 2.3.0-rc1 of Apache IvyDE
On 27/06/18 10:12 PM, Nicolas Lalevée wrote: Since there is a work around (hitting refresh after resolve) and it is an RC, we could ship it like that and fix it later. But due to the automatic update via the update site, I bet most users will update even if it is an RC. So I am not sure what I should vote. So I vote -0 for me for now. I was reserving my vote just for this reason. I don't use Eclipse so I wanted to see if someone more familiar with it has an opinion about this bug. You are right that it's going to end up affecting everyone once we release this. Given that the purpose of this release is revive this project a bit and not break setups where things are working fine and the fact that this will end up being an annoying kind of workaround (having to hit refresh after resolve), I don't see rushing this release without fixing this issue serves any purpose. So I'll vote a -1 on this now. I know we have gone through 3 voting rounds for this release, so thank you everyone for being patient and testing out the binaries. I'll file this issue in JIRA and hopefully spend some time in Eclipse this weekend to try and sort this out. -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [Bug 33169] KIndly update the date feature
Just curious about our bugzilla infrastructure - do random users get to change the content of these bugs, even if they aren't the ones who reported the issue? -Jaikiran On 28/06/18 9:05 AM, bugzi...@apache.org wrote: https://bz.apache.org/bugzilla/show_bug.cgi?id=33169 Ranjeet Mane changed: What|Removed |Added Summary|ClearCase update produces |KIndly update the date |verbose output---request|feature |standard output suppression | |feature | Component|Optional SCM tasks |Core - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
[VOTE] Release 2.3.0-rc1 of Apache IvyDE
I'm initiating a newer vote mail for 2.3.0-rc1 release of Apache IvyDE project. This addresses the blocker issue that Nicolas identified, the last time a vote was initiated for this version. The newly updated tag is here https://git-wip-us.apache.org/repos/asf?p=ant-ivyde.git;a=tag;h=refs/tags/2.3.0-rc1 with sha1 3581a61ec159ede16005f36e58e5e258d32090fa You can download the distribution from this URL: https://dist.apache.org/repos/dist/dev/ant/ivyde/2.3.0-rc1/ at rev 27709 The Eclipse p2 repository is here: https://dist.apache.org/repos/dist/dev/ant/ivyde/updatesite/ivyde-2.3.0.rc1-201806251008-RELEASE/ at rev 27707 The 2.3.0-rc1 release of IvyDE consists of the following changes: * FIX: xml bomb in workspace causes hang in Ivy code during Search or Synchronize operations (https://issues.apache.org/jira/browse/IVYDE-354) * FIX: Deadlock in classpath container (https://issues.apache.org/jira/browse/IVYDE-361) * FIX: Typo in IvyResolveJob (https://issues.apache.org/jira/browse/IVYDE-362) * FIX: User-selected configurations not checked in the viewer (https://issues.apache.org/jira/browse/IVYDE-378) * FIX: Fix ClassCastException (https://issues.apache.org/jira/browse/IVYDE-386) * FIX: Fix the issue where the IvyDE preferences couldn't be saved (https://issues.apache.org/jira/browse/IVYDE-388) * NEW: Support for OSGi 'Bundle-Classpath' directive * NEW: Basic support for the workspace resolver to find OSGi bundles managed by Ivy in the workspace * NEW: Support for storing credentials securely Do you vote for the release of these binaries? -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [VOTE] Release AntUnit 1.4 based on RC3
+1. - Downloaded the .tar.gz binary - Checked some of the docs/manual - Ran a simple project using this released version - Checked the NOTICE file All looks fine. -Jaikiran On 22/06/18 11:02 AM, Stefan Bodewig wrote: Hi all this is the third RC for AntUnit 1.4 with the problems Gintas identified fixed. tag: https://git-wip-us.apache.org/repos/asf?p=ant-antlibs-antunit.git;a=tag;h=fb7a42470f8a6de50686f37519e27a068c576606 tarballs: https://dist.apache.org/repos/dist/dev/ant/antlibs/antunit/ svn revision 27641 Maven artifacts: https://repository.apache.org/content/repositories/orgapacheant-1033/org/apache/ant/ant-antunit/1.4/ vote will be open for 72 hours and not close before 2018-06-25 05:30 UTC. Stefan - 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
Re: [ANN] Apache Ant 1.9.12 and 1.10.4 Released
Thank you for running this release, Stefan. -Jaikiran On 22/06/18 9:09 PM, Stefan Bodewig wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The Apache Ant Team is pleased to announce the releases of Apache Ant 1.9.12 and 1.10.4. Apache Ant is a Java library and command-line tool that helps building software. The Apache Ant team currently maintains two lines of development. The 1.9.x releases require Java5 at runtime and 1.10.x requires Java8 at runtime. Both lines are based off of Ant 1.9.7 and the 1.9.x releases are mostly bug fix releases while additional new features are developed for 1.10.x. We recommend using 1.10.4 unless you are required to use versions of Java prior to Java8 during the build process. Ant 1.10.4 contains a superset of 1.9.12 - with the exception of a few tasks and features that no longer work with Java8 anyway (like the apt task). Both releases are mostly bug fix releases with a few new features being added. In both releases the untar, unjar and unzip will no longer extract entries whose names would make the created files be placed outside of the destination directory by default. This is based on a recommendation by the Snyk Security Research Team. Source and binary distributions are available for download from the Apache Ant download site: http://ant.apache.org/bindownload.cgi http://ant.apache.org/srcdownload.cgi When downloading, please verify signatures using the KEYS file available at the above location when downloading the release. Changes in 1.10.4 include: == Changes that could break older environments: - --- * , and will no longer extract entries whose names would make the created files be placed outside of the destination directory anymore by default. A new attribute allowFilesToEscapeDest can be used to override the behavior. Another special case is when stripAbsolutePathSpec is false (which no longer is the default) and the entry's name starts with a (back)slash and allowFilesToEscapeDest hasn't been specified explicitly, in this case the file may be created outside of the dest directory as well. In addition stripAbsolutePathSpec is now true by default. Based on a recommendation by the Snyk Security Research Team. Fixed bugs: - --- * Delay the class initialization of the test classes until they are passed to JUnit. This way we can avoid that failing static initializers from non-test classes are reported as error when the 'skipNonTests' option is 'true'. Bugzilla Report 60062 * The junit task when used with includeantruntime="no" was incorrectly printing a warning about multiple versions of ant detected in path * died with a NullPointerException since Ant 1.10.2. Bugzilla Report 62335 * The task would fail with "java.lang.ClassFormatError: Invalid Constant Pool entry Type 19" while parsing a module-info.class. The task is compatible with Java bytecode version 53 now. Bug reported by Simon IJskes https://issues.apache.org/jira/browse/NETBEANS-781 * Default and SecureInputHandler will now raise an error when then end of the input stream (usually System.in or System.console) are reached before a valid input has been read. * junitreport does not list testsuites that fail to start any tests because of an exception inside the all-tests and alltests-errors frames. Bugzilla Report 62443 Other changes: - -- * AntAssert is deprecated, assertThat from JUnit 4.4+, Hamcrest matchers and/or ExpectedException rule provide equivalent functionality * PumpStreamHandler now explicitly verifies the streams for output and error are not null and will throw an exception if they are. This way creating a PumpStreamHandler will fail early as opposed to some obscure errors later when closing streams or finishing threads might fail. Bugzilla Report 62148 * has a new attribute runtime which can be used to set properties with values taken as snapshots from the availableProcessors, freeMemory, maxMemory and totalMemory methods of the Java Runtime class. * linecontains filter now has a new "matchAny" attribute which when set to "true" allows any (instead of all) of the user-specified strings to be present in the line. Bugzilla Report 62313 * has a new basedir attribute that can be used to resolve relative names and provides a root for the FileResources generated. Bugzilla Report 62379 * The and nested elements of and now support an encoding attribute that can be used to specify the file's encoding. Bugzilla Report 62379 * New file selectors, posixGroup and posixPermissions, are available. The new selectors and related ownedBy selector have "followSymlinks" attribute that defaults to &q
Re: [VOTE] Release Ant 1.10.4 based on RC1
+1. - Downloaded the .tar.gz binary - Checked some docs in the manual - Used this new version to run builds against existing internal Ant projects. All went fine. -Jaikiran On 19/06/18 12:38 PM, Stefan Bodewig wrote: Hi all I've created a new release candidate for 1.10.4 with a bunch of bug fixes and the "ZipSlip" adjustment. git tag: ANT_1.10.4_RC1 on commit: 9dc3e788b tarballs: https://dist.apache.org/repos/dist/dev/ant/ revision: 27553 Maven artifacts: https://repository.apache.org/content/repositories/orgapacheant-1031/org/apache/ant/ This Vote will be open at least for 72 hours and close no earlier than 2018-06-22 08:30UTC. Cheers Stefan - 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
Re: [CANCELLED] Release AntUnit 1.4 Based on RC2
I think moving to Ant 1.8.x would be a better option, given the relatively low chances of it causing any issues. -Jaikiran On 21/06/18 2:47 PM, Stefan Bodewig wrote: On 2018-06-21, Gintautas Grigelionis wrote: POM template has inconsistent Ant versions, 1.7.1 in compile scope and 1.8.1 in provided scope. True. This happened in c3f8655 which updated the dependencies to 1.8.1 because one of the unit tests used a method of ant-testutil that hasn't been present in Ant 1.7. We could fix the test or explicitly document Ant 1.8.x as new requirement - which really doesn't exist except for the tests. The upgrade would be a breaking change but I don't expect it would break anything in real life. Some of the other antlibs may require Ant 1.7 but the only other one I'd expect to get new releases (Compress) is at 1.8 already, so upgrading the dependency probably doesn't do any harm to them. Any opinions? Stefan - 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
Re: [VOTE] Release Ant 1.9.12 based on RC1
+1. - Downloaded the .tar.gz binary - Installed locally, checked the NOTICE and some tasks' manuals. Look fine. - Built some random existing Ant based projects using this new version. All went fine. -Jaikiran On 19/06/18 12:38 PM, Stefan Bodewig wrote: Hi all I've created a new release candidate for 1.9.12 with a bunch of bug fixes and the "ZipSlip" adjustment. git tag: ANT_1_9_12_RC1 on commit: 6e694d820 tarballs: https://dist.apache.org/repos/dist/dev/ant/ revision: 27552 Maven artifacts: https://repository.apache.org/content/repositories/orgapacheant-1030/org/apache/ant/ This Vote will be open at least for 72 hours and close no earlier than 2018-06-22 08:30UTC. Cheers Stefan - 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
Re: .git(modules|attributes|ignore) files in source dists?
I don't have a preference on whether or not to include the SCM related files, but at least in the recent IvyDE release process, I setup the build to use "git archive" command to generate these source tar/zip packages[1]. The documentation of git archive doesn't explicitly state anything about files like .gitignore being packaged into the archive. So I looked into the generated source tar and those are indeed present. I actually can't think of a reason why we should exclude these files. [1] https://github.com/apache/ant-ivyde/blob/master/build.xml -Jaikiran On 19/06/18 8:12 PM, Stefan Bodewig wrote: Hi all when I set up the build for AntUnit I realized the source tarball didn't contain the git config files that are part of the source repo and changed the antlibs-common module to include them (they are part of Ant's defaultexcludes for DirectoryScanner). Later it dawned on me this may not be a good idea as we don't include anything else that is SCM related either, so maybe not including the files has been the correct choice all along. Any opinions on whether we should include or exclude them? Stefan - 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
Re: [VOTE] Release AntUnit 1.4 Based on RC1
- Downloaded the tarballs (both source and binaries). Installed locally. - Verified the checksum file. All fine. - Ran a few antunit tests via simple Ant build files. All fine. This all looked fine. There are some minor issues though: 1. The NOTICE file copyright year is 2005-2014 2. The docs/index.html points to an incorrect location for source code: The source code for the library lives in the ant-antlibs-antunit git repository - http://svn.apache.org/viewcvs.cgi/ant/antlibs/antunit/trunk/";>https://git-wip-us.apache.org/repos/asf/ant-antlibs-antunit.git. The text of that link has the right location, however the actual href points to the SVN repo. 3. The docs/assert.html has a typo in its example: The closing assertTrue tag is malformed. This specific typo isn't a blocker IMO, for the release. Neither do I consider the index.html repo link typo to be a blocker. I don't know if the copyright year issue should warrant a new vote. If it doesn't, then it's a +1 for this release from me. -Jaikiran On 19/06/18 1:27 AM, Stefan Bodewig wrote: On 2018-06-18, Stefan Bodewig wrote: Hi all there haven't been big changes but the race condition has been nagging us, so I've prepared artifacts to release them as AntUnit 1.4. tag: https://git-wip-us.apache.org/repos/asf?p=ant-antlibs-antunit.git;a=tag;h=c4af2e6f2ff632b896a15e7611e01b36bf4eada9 tarballs: https://dist.apache.org/repos/dist/dev/ant/antlibs/antunit/ svn revision 27536 Maven artifacts: https://git-wip-us.apache.org/repos/asf?p=ant-antlibs-antunit.git;a=tag;h=c4af2e6f2ff632b896a15e7611e01b36bf4eada9 sorry, Maven artifacts: https://repository.apache.org/content/repositories/orgapacheant-1029/org/apache/ant/ant-antunit/1.4/ - 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
[CANCEL] [VOTE] Apache IvyDE 2.3.0-rc1 release
Given the nature of this issue, I'm cancelling this vote. A new one will be initiated this week. -Jaikiran On 19/06/18 5:05 AM, Jaikiran Pai wrote: Thanks for testing this Nicolas. This indeed is a big enough issue to be considered a blocker. I'll take a look at this. I'll also include the sha and rev in a newer vote and update our release instructions. -Jaikiran On Tuesday, June 19, 2018, Nicolas Lalevée <mailto:nicolas.lale...@hibnet.org>> wrote: > First, thank you very much Jaikiran to make this release happen. > > So checksum, signatures, installation, build, resolve on projects went well. But I have found a regression: global preferences cannot be saved anymore. > cf https://issues.apache.org/jira/browse/IVYDE-388 <https://issues.apache.org/jira/browse/IVYDE-388> > > Looking at the code, indeed it cannot work. > https://github.com/apache/ant-ivyde/blob/c92ed1b9247642dfaa67e5cf84528cfa20931c47/org.apache.ivyde.eclipse/src/java/org/apache/ivyde/internal/eclipse/ui/preferences/PreferenceConstants.java#L136 <https://github.com/apache/ant-ivyde/blob/c92ed1b9247642dfaa67e5cf84528cfa20931c47/org.apache.ivyde.eclipse/src/java/org/apache/ivyde/internal/eclipse/ui/preferences/PreferenceConstants.java#L136> > > I think it deserves to be fixed before being consumed by end users. > So -1 for me. > > Also, it will be better to mention the sha1 of the git tag and the svn revision of the artifact in dist. We should update the release instructions to not forgot it, like I have done for the last release of Ivy: > https://github.com/apache/ant-ivy/blob/master/asciidoc/dev/makerelease.adoc#11-call-for-a-vote-to-approve-the-release <https://github.com/apache/ant-ivy/blob/master/asciidoc/dev/makerelease.adoc#11-call-for-a-vote-to-approve-the-release> > > Nicolas > >> Le 17 juin 2018 à 08:45, Jaikiran Pai <mailto:jai.forums2...@gmail.com>> a écrit : >> >> This is a newer vote mail that I'm initiating for the 2.3.0-rc1 release of IvyDE. >> >> The newly updated tag is here https://git1-us-west.apache.org/repos/asf?p=ant-ivyde.git;a=commit;h=refs/tags/2.3.0-rc1 >> >> You can download the distribution from this URL: https://dist.apache.org/repos/dist/dev/ant/ivyde/2.3.0-rc1/ >> >> The Eclipse p2 repository is here: https://dist.apache.org/repos/dist/dev/ant/ivyde/updatesite/ivyde-2.3.0.rc1-201806171016-RELEASE/ >> >> The 2.3.0-rc1 release of IvyDE consists of the following changes: >> >> * FIX: xml bomb in workspace causes hang in Ivy code during Search or Synchronize operations (https://issues.apache.org/jira/browse/IVYDE-354) >> * FIX: Deadlock in classpath container (https://issues.apache.org/jira/browse/IVYDE-361) >> * FIX: Typo in IvyResolveJob (https://issues.apache.org/jira/browse/IVYDE-362) >> * FIX: User-selected configurations not checked in the viewer (https://issues.apache.org/jira/browse/IVYDE-378) >> * FIX: Fix ClassCastException (https://issues.apache.org/jira/browse/IVYDE-386) >> >> * NEW: Support for OSGi 'Bundle-Classpath' directive >> * NEW: Basic support for the workspace resolver to find OSGi bundles managed by Ivy in the workspace >> * NEW: Support for storing credentials securely >> >> >> Do you vote for the release of these binaries? >> >> >> -Jaikiran >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org <mailto:dev-unsubscr...@ant.apache.org> >> For additional commands, e-mail: dev-h...@ant.apache.org <mailto:dev-h...@ant.apache.org> >> > >
Re: [VOTE] Apache IvyDE 2.3.0-rc1 release
Thanks for testing this Nicolas. This indeed is a big enough issue to be considered a blocker. I'll take a look at this. I'll also include the sha and rev in a newer vote and update our release instructions. -Jaikiran On Tuesday, June 19, 2018, Nicolas Lalevée wrote: > First, thank you very much Jaikiran to make this release happen. > > So checksum, signatures, installation, build, resolve on projects went well. But I have found a regression: global preferences cannot be saved anymore. > cf https://issues.apache.org/jira/browse/IVYDE-388 < https://issues.apache.org/jira/browse/IVYDE-388> > > Looking at the code, indeed it cannot work. > https://github.com/apache/ant-ivyde/blob/c92ed1b9247642dfaa67e5cf84528cfa20931c47/org.apache.ivyde.eclipse/src/java/org/apache/ivyde/internal/eclipse/ui/preferences/PreferenceConstants.java#L136 < https://github.com/apache/ant-ivyde/blob/c92ed1b9247642dfaa67e5cf84528cfa20931c47/org.apache.ivyde.eclipse/src/java/org/apache/ivyde/internal/eclipse/ui/preferences/PreferenceConstants.java#L136 > > > I think it deserves to be fixed before being consumed by end users. > So -1 for me. > > Also, it will be better to mention the sha1 of the git tag and the svn revision of the artifact in dist. We should update the release instructions to not forgot it, like I have done for the last release of Ivy: > https://github.com/apache/ant-ivy/blob/master/asciidoc/dev/makerelease.adoc#11-call-for-a-vote-to-approve-the-release < https://github.com/apache/ant-ivy/blob/master/asciidoc/dev/makerelease.adoc#11-call-for-a-vote-to-approve-the-release > > > Nicolas > >> Le 17 juin 2018 à 08:45, Jaikiran Pai a écrit : >> >> This is a newer vote mail that I'm initiating for the 2.3.0-rc1 release of IvyDE. >> >> The newly updated tag is here https://git1-us-west.apache.org/repos/asf?p=ant-ivyde.git;a=commit;h=refs/tags/2.3.0-rc1 >> >> You can download the distribution from this URL: https://dist.apache.org/repos/dist/dev/ant/ivyde/2.3.0-rc1/ >> >> The Eclipse p2 repository is here: https://dist.apache.org/repos/dist/dev/ant/ivyde/updatesite/ivyde-2.3.0.rc1-201806171016-RELEASE/ >> >> The 2.3.0-rc1 release of IvyDE consists of the following changes: >> >> * FIX: xml bomb in workspace causes hang in Ivy code during Search or Synchronize operations (https://issues.apache.org/jira/browse/IVYDE-354) >> * FIX: Deadlock in classpath container ( https://issues.apache.org/jira/browse/IVYDE-361) >> * FIX: Typo in IvyResolveJob ( https://issues.apache.org/jira/browse/IVYDE-362) >> * FIX: User-selected configurations not checked in the viewer ( https://issues.apache.org/jira/browse/IVYDE-378) >> * FIX: Fix ClassCastException ( https://issues.apache.org/jira/browse/IVYDE-386) >> >> * NEW: Support for OSGi 'Bundle-Classpath' directive >> * NEW: Basic support for the workspace resolver to find OSGi bundles managed by Ivy in the workspace >> * NEW: Support for storing credentials securely >> >> >> Do you vote for the release of these binaries? >> >> >> -Jaikiran >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org >> For additional commands, e-mail: dev-h...@ant.apache.org >> > >
Re: [VOTE] Apache IvyDE 2.3.0-rc1 release
+1. Tried the installation and used a basic Ivy based project for dependency resolution. Also checked some of the Ivy plugin screens to make sure all is fine. -Jaikiran On 17/06/18 12:15 PM, Jaikiran Pai wrote: This is a newer vote mail that I'm initiating for the 2.3.0-rc1 release of IvyDE. The newly updated tag is here https://git1-us-west.apache.org/repos/asf?p=ant-ivyde.git;a=commit;h=refs/tags/2.3.0-rc1 You can download the distribution from this URL: https://dist.apache.org/repos/dist/dev/ant/ivyde/2.3.0-rc1/ The Eclipse p2 repository is here: https://dist.apache.org/repos/dist/dev/ant/ivyde/updatesite/ivyde-2.3.0.rc1-201806171016-RELEASE/ The 2.3.0-rc1 release of IvyDE consists of the following changes: * FIX: xml bomb in workspace causes hang in Ivy code during Search or Synchronize operations (https://issues.apache.org/jira/browse/IVYDE-354) * FIX: Deadlock in classpath container (https://issues.apache.org/jira/browse/IVYDE-361) * FIX: Typo in IvyResolveJob (https://issues.apache.org/jira/browse/IVYDE-362) * FIX: User-selected configurations not checked in the viewer (https://issues.apache.org/jira/browse/IVYDE-378) * FIX: Fix ClassCastException (https://issues.apache.org/jira/browse/IVYDE-386) * NEW: Support for OSGi 'Bundle-Classpath' directive * NEW: Basic support for the workspace resolver to find OSGi bundles managed by Ivy in the workspace * NEW: Support for storing credentials securely Do you vote for the release of these binaries? -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: thinking about new releases
I am willing to test and vote on an AntUnit release. -Jaikiran On 18/06/18 12:45 PM, Stefan Bodewig wrote: OK, then I'll revert the antunit change so the source release ships with a released version of it and prepare release candidates sometime the coming days. The alternative would be to cut an AntUnit release first which also works for me if enough people are willing to vote on that. Stefan - 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
Re: svn commit: r27516 - /release/ant/KEYS
Thank you Stefan, I forgot to add it to this location and added only in the git repo. -Jaikiran On 17/06/18 2:00 PM, bode...@apache.org wrote: Author: bodewig Date: Sun Jun 17 08:30:47 2018 New Revision: 27516 Log: Add Jaikiran's key Modified: release/ant/KEYS Modified: release/ant/KEYS == --- release/ant/KEYS (original) +++ release/ant/KEYS Sun Jun 17 08:30:47 2018 @@ -1426,3 +1426,62 @@ Ci8LBeDYqitVqqakgdKGAl8pfwaIJ9DsE5Sv/IHK 3PimOFurhebU3wOU0wEkNb/3IYLk+MFQOA== =1STU -END PGP PUBLIC KEY BLOCK- +pub rsa4096 2018-06-13 [SC] [expires: 2022-06-13] + 8DA70C00DF7AF1B0D2F9DC74DDBCC1270A29D081 +uid [ultimate] jaikiran@apache +sig 3DDBCC1270A29D081 2018-06-13 jaikiran@apache +sub rsa4096 2018-06-13 [E] [expires: 2022-06-13] +sig DDBCC1270A29D081 2018-06-13 jaikiran@apache + +-BEGIN PGP PUBLIC KEY BLOCK- + +mQINBFsgsskBEACy8rzosITgdGsfQijFhWkRo/iyXv7LdSD5FezMu6C4UosENKlP +85y0XBsE3Z7K50uxVizyjXTetK+EIS684c6pU1t0vbWyvJzSgHeqf0GEaqiUNWTo +9Jk6jAaeYeNu+6/TVUCYrb+zmQqmJPZq5W4FvTnpRed/t4zBPLlFPe2+QNaNRE03 +JqCrnmih0hrxVcM5jyynXSozuS50DcMuiOCZL3zPBW6mDGaXH6+yUfFVrReuCB// +D0u0sCSiV5TvhSh2+8lLUG5tuvOKfg2SlRFtF9JQIPsm/qV/fK2muW2mc+Ti0n+k +3gzxtr4eC5YvShJCe0DoxR9q/CItx6vRg8h+G4HhL1P5N+Tj4N0zfcUs/2vaJbm3 +LrjK8o+coNa8dgiIN6AbdcS8szIRYUG2MJzUI1mggYw/i4YcnNhrKTPZtdbKRfmK +AIq1d1eEt/rJ97ypTzeYO6jq6Jkmnb3rWzmx9XA9Mo4J8X7587E6zkiD3FoFrSaM +o20q+byMuXC8kKIEiDOa7UFQUh1ku8RDAmjXlWwqw3+RtrRt0TXoHRNWRoShiBee +TjkQ3ZW7FlSk1hs80qeVCcSJ6lf1texmZzonAJCyibEWdzvceGvs2/PenetsnP/5 +nDlJuEs4jhoYuU57HjXfcSSOqmLAFAym7pL0Yd+KNhvxjBF/SoJ1wgoLBQARAQAB +tCVqYWlraXJhbkBhcGFjaGUgPGphaWtpcmFuQGFwYWNoZS5vcmc+iQJUBBMBCAA+ +FiEEjacMAN968bDS+dx03bzBJwop0IEFAlsgsskCGwMFCQeGH4AFCwkIBwIGFQoJ +CAsCBBYCAwECHgECF4AACgkQ3bzBJwop0IECdA/+OTyhXffGztoNrvIYF9tamNCV +T5dzzY9qOos6pHShgX6O3xic33UMt3O6ec6RSILEmc1IJlthmxVTsu0XJ57+eDYJ +zzA1JYD1RkLcS6+aqmopfoPdpzOftshQ8yEXPKQl69IhKn0B6yQc98d3EHYQtun0 +t9fwQA3LGoMWH7RIsFycMKi6+Z6TOaLdkpNs9ipuIGkouNdqdVTIgQGBmHvQwgO6 +r6mYSiApE7lQ8+s/7J1hJuA3GzV9gQ8DK9g0hr1E1EmbG9enxn2XT2V4H4hXFJfr +CEYjMTsa6EYEOnA4BqwMmBHx2LOClydhPOJbc3/09XzAUdwUsxbVgByZ1kUvfo76 +eLYC2/YXtyVluLyYwUyGLXlBWMChHM+AIVyTg7HNVvFF99cwdpBgpDjUFx60+ftY +fFxXJJbu4lq1ULKOyqqoDwaebp2C/gZ3bIVmqZ2GFUCoeIuBh94pRhENK/O0FBua +Bp3mYaGrpDVMglu1p9lxz0H2uuAUgXu1hRM7GWbq5TWUKcD/zb6NH7DO82cRqCJE +n//p3Wqc4tAZt8B3bQGQWRGQ3iOU8RxmDvyneuVyqWR0dIkb7ByjtD7SKRkSomNq +6o6mw+Kuj+6M0dwhZdmPB8O/RiLLJDKL83DZN6P+yEBIsc73qS3QPnCuvENPfxgm +0JI2d63wnXbW4bkOzN+5Ag0EWyCyyQEQAKwUmKfCA62QiJwk+NAHfVmrXgk6lpSC +ExCjC8RvWgt7R6upLfOdKFLRLNR4aybLF9/XcW5rsmfF7eTonsA3vnIsfLHtLazL +MoUVgj9jZjlvjcxWX5F8pXL7BH0x443GZvZNIdIt9SCOPJUKVZfc9VCcvw564E8q +IbFJBSCPVMTibPNLZw5N3Iv5WfdqRsIg70jURqiSOMDnn1VpXid0X5iU0ruqlqi5 +giud8p/1isBtVQyiGmpDs2UoPaUFUxmIWJ/srxNx5fAyOKd2WsWALn0nJuaIlL0A +25zTzLU3WpTkHFvimWH8ogonXtjLQfh70GJ4NjBhIAjtQFVptGGNLleDVTD1AIMN +imc7GxFGf4EUAgK8fcDrF6WtLtK3QnA3hSXHMgzpLo1NmirWy1cfvwNwnse7KCX/ ++axld1slAgnNZl3UADj2irI/j1bl2ntsriE0Q1N+n729G3zlkg0Twj/IjPxo1PW6 +5A7b62PDhGtajdwfPKM43dHgJ8ZYGL/zaKt4elhsVQPBZcUOl6YV9fg9c5jqAJhU +IbhfuyQW+/EGYnR4/2G3wbIKiYPsuBiQw4nN1IdGTpfoW9DymYpIcrLJZkt2/4qe +SxXxHa1/qF7CjOoNV5Vza17+mLRS2NN7/Hz+lcyIuYf7dzLJ/U/DIyK4QBcCqm72 +9ISsCgK2Hbd3ABEBAAGJAjwEGAEIACYWIQSNpwwA33rxsNL53HTdvMEnCinQgQUC +WyCyyQIbDAUJB4YfgAAKCRDdvMEnCinQgTfiD/9C1jk1iTIeh8KZDQOEkwVXEjIw +Dng0fxSq3ICNjyH58JGysFbOTIyVoqaDPcIWM5/IAbF4DpuXZvaVu0nufpVKupIi +Lq2jRwXC14G+gC/BEsB7KVqzoon/zhKlHEo6sVtumckFVtjXG9SfAqf3q8rSGwaS +WzSOrg7gyKznizOPBWs1kkJ9h+Paj48uP9EUYIr+s8BVlXSRr4TDF++/drPhZ2sz +uphS8fr1fedfaBD++xMmpGEGE2KenTk3oBjvBHusHsSdoqw8IaZ0Bhc4vajuqHWE +4nacvBGaIp5so5kA+MFf69l/G/+cWj+PP7xuGPy9TkqKXi8CNdQE1iEa6UKhBYaA +xpRzaugIDDhSnu9WcoaGixpGVCYojRW1+OloumEhl7WkiWfq3db0q/+uoSJEPqmQ +M7+i7Z6/vPI/3Nu+NvFsDygQA97FF1Tl1ISxfWgd3YplQjuTLLyawxWT7fHKCrx4 +TjUM+JPy+xGDd/RP/YksSfM9dsV/EEruN02qBDoUADpuhw0vkKC/OAxuLkWDm0h9 +S3vUQ3zGioMMYLvbNe8rAP3VC5fJ7H80spv/z05JfO7c4hutU8D0ykQ0ZNuWdL79 +2HEociC3YdVmiCxmvsabeeOeMVU0WgFSHjPRqfPnoSu4ytA0Szn2dsZ64VV01BHm +3rZzxBZRMmQz3CJrMw== +=vLW3 +-END PGP PUBLIC KEY BLOCK- - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: thinking about new releases
+1. I don't have anything in a state that I can push to either of these branches, in the immediate future. -Jaikiran On 16/06/18 9:38 PM, Stefan Bodewig wrote: Hi all given https://dev.snyk.io/research/zip-slip-vulnerability lists Ant 1.9.12 as a release fixing a security problem it might be a good idea to actually release 1.9.12 :-) AFAICS there is no unfinished work in either branch, but I may be wrong. I am aware there ar enhancement requests around javadoc that may be worth waiting for for 1.10.x. Is anybody else planning to do something that should be finished before creating release candidates? Stefan - 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
Re: [VOTE] Apache IvyDE 2.3.0-rc1 release
I pushed a bunch of commits to address these issues and have now released newer binaries for 2.3.0-rc1 release and initiated a separate VOTE mail for it. -Jaikiran On 16/06/18 6:48 PM, Stefan Bodewig wrote: Hi please add your PGP key to dist.apache.org/release/ant/KEYS * checksums and signatures are good * for the files in updatesite it still contains .md5 and .sha but nothing stronger, please add stronger hashes and remove the md5 files unless they are read by eclipse * source tarball and tag differ slightly (build.properties and releaese.adoc) * the source tarball extracts everything to the current directory unlike the binary tarball which creates a subdirectory apache-ivyde-2.3.0.rc1-201806132023-RELEASE - I'm not complaining but it seems inconsistent * org.apache.ivyde.eclipse.resolvevisualizer.feature_2.3.0.rc1-201806132023-RELEASE.jar lacks LICENSE and NOTICE files I'd prefer org.apache.ivyde.eclipse.resolvevisualizer.feature_2.3.0.rc1-201806132023-RELEASE.jar to be fixed for this release and will vote -1 on a next release for such an issue. The tag/source difference is acceptable to me but shouldn't happen. My vote is a +0 Stefan - 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
[VOTE] Apache IvyDE 2.3.0-rc1 release
This is a newer vote mail that I'm initiating for the 2.3.0-rc1 release of IvyDE. The newly updated tag is here https://git1-us-west.apache.org/repos/asf?p=ant-ivyde.git;a=commit;h=refs/tags/2.3.0-rc1 You can download the distribution from this URL: https://dist.apache.org/repos/dist/dev/ant/ivyde/2.3.0-rc1/ The Eclipse p2 repository is here: https://dist.apache.org/repos/dist/dev/ant/ivyde/updatesite/ivyde-2.3.0.rc1-201806171016-RELEASE/ The 2.3.0-rc1 release of IvyDE consists of the following changes: * FIX: xml bomb in workspace causes hang in Ivy code during Search or Synchronize operations (https://issues.apache.org/jira/browse/IVYDE-354) * FIX: Deadlock in classpath container (https://issues.apache.org/jira/browse/IVYDE-361) * FIX: Typo in IvyResolveJob (https://issues.apache.org/jira/browse/IVYDE-362) * FIX: User-selected configurations not checked in the viewer (https://issues.apache.org/jira/browse/IVYDE-378) * FIX: Fix ClassCastException (https://issues.apache.org/jira/browse/IVYDE-386) * NEW: Support for OSGi 'Bundle-Classpath' directive * NEW: Basic support for the workspace resolver to find OSGi bundles managed by Ivy in the workspace * NEW: Support for storing credentials securely Do you vote for the release of these binaries? -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
[CANCEL] [VOTE] Apache IvyDE 2.3.0-rc1 release
Given some of the valid issues that Stefan has raised with this released instance, I'm cancelling this vote. This is a first release after a long time and I plan to have this as clean as possible. I will send out a new vote mail once I sort out these issues. -Jaikiran On 16/06/18 6:48 PM, Stefan Bodewig wrote: Hi please add your PGP key to dist.apache.org/release/ant/KEYS * checksums and signatures are good * for the files in updatesite it still contains .md5 and .sha but nothing stronger, please add stronger hashes and remove the md5 files unless they are read by eclipse * source tarball and tag differ slightly (build.properties and releaese.adoc) * the source tarball extracts everything to the current directory unlike the binary tarball which creates a subdirectory apache-ivyde-2.3.0.rc1-201806132023-RELEASE - I'm not complaining but it seems inconsistent * org.apache.ivyde.eclipse.resolvevisualizer.feature_2.3.0.rc1-201806132023-RELEASE.jar lacks LICENSE and NOTICE files I'd prefer org.apache.ivyde.eclipse.resolvevisualizer.feature_2.3.0.rc1-201806132023-RELEASE.jar to be fixed for this release and will vote -1 on a next release for such an issue. The tag/source difference is acceptable to me but shouldn't happen. My vote is a +0 Stefan - 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
Re: [VOTE] Apache IvyDE 2.3.0-rc1 release
Thanks Stefan, I'll fix these issues and send out a new voting mail. -Jaikiran On Saturday, June 16, 2018, Stefan Bodewig wrote: > Hi > > please add your PGP key to dist.apache.org/release/ant/KEYS > > * checksums and signatures are good > * for the files in updatesite it still contains .md5 and .sha but > nothing stronger, please add stronger hashes and remove the md5 files > unless they are read by eclipse > * source tarball and tag differ slightly (build.properties and > releaese.adoc) > * the source tarball extracts everything to the current directory unlike > the binary tarball which creates a subdirectory > apache-ivyde-2.3.0.rc1-201806132023-RELEASE - I'm not complaining but > it seems inconsistent > * org.apache.ivyde.eclipse.resolvevisualizer.feature_2.3.0.rc1-201806132023-RELEASE.jar > lacks LICENSE and NOTICE files > > I'd prefer > org.apache.ivyde.eclipse.resolvevisualizer.feature_2.3.0.rc1-201806132023-RELEASE.jar > to be fixed for this release and will vote -1 on a next release for such > an issue. The tag/source difference is acceptable to me but shouldn't > happen. > > My vote is a +0 > > Stefan > > - > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > For additional commands, e-mail: dev-h...@ant.apache.org > >
Re: [VOTE] Apache IvyDE 2.3.0-rc1 release
I tried reproducing this issue but haven't been able to. Either way, given the nature of this issue, I personally don't consider it a blocker for this release vote to pass. Please do file a JIRA with the relevant details if this is reproducible. -Jaikiran On 14/06/18 12:53 AM, Gintautas Grigelionis wrote: Another issue with UX on Oxygen: Ivy container icon in Package Explorer seems to disappear after "Reload settings" and reappear after "Refresh". Gintas Den ons 13 juni 2018 kl 21:06 skrev Gintautas Grigelionis < g.grigelio...@gmail.com>: I am testing on Oxygen 3.A and seeing errors like org.xml.sax.SAXParseException; systemId: http://ant.apache.org/ivy/ivyde/updatesite/p2-mirrors--xml.cgi?path=ivyde-2.3.0.rc1-201806132023-RELEASE&countryCode=se&timeZone=1&format=xml; lineNumber: 39; columnNumber: 3; Element type "link" lack matching end tag "". Gintas Den ons 13 juni 2018 kl 17:48 skrev Jaikiran Pai : I have built a release candidate 2.3.0-rc1 for Apache IvyDE. The tag is here: https://git1-us-west.apache.org/repos/asf?p=ant-ivyde.git;a=commit;h=refs/tags/2.3.0-rc1 You can download the distribution from this URL: https://dist.apache.org/repos/dist/dev/ant/ivyde/2.3.0-rc1 The Eclipse p2 repository is there: https://dist.apache.org/repos/dist/dev/ant/ivyde/updatesite/ivyde-2.3.0.rc1-201806132023-RELEASE/ This release consists of the following changes: * FIX: xml bomb in workspace causes hang in Ivy code during Search or Synchronize operations (https://issues.apache.org/jira/browse/IVYDE-354) * FIX: Deadlock in classpath container (https://issues.apache.org/jira/browse/IVYDE-361) * FIX: Typo in IvyResolveJob (https://issues.apache.org/jira/browse/IVYDE-362) * FIX: User-selected configurations not checked in the viewer (https://issues.apache.org/jira/browse/IVYDE-378) * FIX: Fix ClassCastException (https://issues.apache.org/jira/browse/IVYDE-386) * NEW: Support for OSGi 'Bundle-Classpath' directive * NEW: Basic support for the workspace resolver to find OSGi bundles managed by Ivy in the workspace * NEW: Support for storing credentials securely Do you vote for the release of these binaries? -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
Re: [VOTE] Apache IvyDE 2.3.0-rc1 release
+1. I did some manual testing of the release which included: - Installing the plugin in Eclipse (Oxygen) - Creating a Eclipse project which uses Ivy and configuring IvyDE usage for it - Adding a simple dependency via Ivy to that project and having it resolved from the IvyDE and using that dependency in a simple Java class. - Checked some Ivy plugin settings page to make sure they look and work fine. -Jaikiran On 13/06/18 9:18 PM, Jaikiran Pai wrote: I have built a release candidate 2.3.0-rc1 for Apache IvyDE. The tag is here: https://git1-us-west.apache.org/repos/asf?p=ant-ivyde.git;a=commit;h=refs/tags/2.3.0-rc1 You can download the distribution from this URL: https://dist.apache.org/repos/dist/dev/ant/ivyde/2.3.0-rc1 The Eclipse p2 repository is there: https://dist.apache.org/repos/dist/dev/ant/ivyde/updatesite/ivyde-2.3.0.rc1-201806132023-RELEASE/ This release consists of the following changes: * FIX: xml bomb in workspace causes hang in Ivy code during Search or Synchronize operations (https://issues.apache.org/jira/browse/IVYDE-354) * FIX: Deadlock in classpath container (https://issues.apache.org/jira/browse/IVYDE-361) * FIX: Typo in IvyResolveJob (https://issues.apache.org/jira/browse/IVYDE-362) * FIX: User-selected configurations not checked in the viewer (https://issues.apache.org/jira/browse/IVYDE-378) * FIX: Fix ClassCastException (https://issues.apache.org/jira/browse/IVYDE-386) * NEW: Support for OSGi 'Bundle-Classpath' directive * NEW: Basic support for the workspace resolver to find OSGi bundles managed by Ivy in the workspace * NEW: Support for storing credentials securely Do you vote for the release of these binaries? -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [VOTE] Apache IvyDE 2.3.0-rc1 release
On 14/06/18 11:50 AM, Stefan Bodewig wrote: On 2018-06-13, Jaikiran Pai wrote: You can download the distribution from this URL: https://dist.apache.org/repos/dist/dev/ant/ivyde/2.3.0-rc1 Be the releas policy that is in place now SHA1 is deprecated, MD5 is frowned upon and at least SHA256 is required for checksums. http://www.apache.org/dev/release-distribution.html#sigs-and-sums You probably need to adjust the build process for future releases, I've fixed the build to use SHA-256 and SHA-512 instead of MD5 and SHA1. for this one could you please add sha256 files manually and remove the md5 files? This is now done. md5 and sha checksum files have been removed and the new ones (as recommended in the release guidelines) have been published at the same location https://dist.apache.org/repos/dist/dev/ant/ivyde/2.3.0-rc1 -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [VOTE] Apache IvyDE 2.3.0-rc1 release
Sure, i'll do that today. -Jaikiran On Thursday, June 14, 2018, Stefan Bodewig wrote: > [As usual I'll only be able to review the legal stuff but probably won't > find time to do so before tomorrow or even Saturday (am currently > traveling).] > > On 2018-06-13, Jaikiran Pai wrote: > >> You can download the distribution from this URL: >> https://dist.apache.org/repos/dist/dev/ant/ivyde/2.3.0-rc1 > > Be the releas policy that is in place now SHA1 is deprecated, MD5 is > frowned upon and at least SHA256 is required for checksums. > > http://www.apache.org/dev/release-distribution.html#sigs-and-sums > > You probably need to adjust the build process for future releases, for > this one could you please add sha256 files manually and remove the md5 > files? > > Stefan > > - > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > For additional commands, e-mail: dev-h...@ant.apache.org > >
Re: [VOTE] Apache IvyDE 2.3.0-rc1 release
Gintas, When and where do you see these messages? What activity triggers it? -Jaikiran On 14/06/18 12:36 AM, Gintautas Grigelionis wrote: I am testing on Oxygen 3.A and seeing errors like org.xml.sax.SAXParseException; systemId: http://ant.apache.org/ivy/ivyde/updatesite/p2-mirrors--xml.cgi?path=ivyde-2.3.0.rc1-201806132023-RELEASE&countryCode=se&timeZone=1&format=xml; lineNumber: 39; columnNumber: 3; Element type "link" lack matching end tag "". Gintas Den ons 13 juni 2018 kl 17:48 skrev Jaikiran Pai : I have built a release candidate 2.3.0-rc1 for Apache IvyDE. The tag is here: https://git1-us-west.apache.org/repos/asf?p=ant-ivyde.git;a=commit;h=refs/tags/2.3.0-rc1 You can download the distribution from this URL: https://dist.apache.org/repos/dist/dev/ant/ivyde/2.3.0-rc1 The Eclipse p2 repository is there: https://dist.apache.org/repos/dist/dev/ant/ivyde/updatesite/ivyde-2.3.0.rc1-201806132023-RELEASE/ This release consists of the following changes: * FIX: xml bomb in workspace causes hang in Ivy code during Search or Synchronize operations (https://issues.apache.org/jira/browse/IVYDE-354) * FIX: Deadlock in classpath container (https://issues.apache.org/jira/browse/IVYDE-361) * FIX: Typo in IvyResolveJob (https://issues.apache.org/jira/browse/IVYDE-362) * FIX: User-selected configurations not checked in the viewer (https://issues.apache.org/jira/browse/IVYDE-378) * FIX: Fix ClassCastException (https://issues.apache.org/jira/browse/IVYDE-386) * NEW: Support for OSGi 'Bundle-Classpath' directive * NEW: Basic support for the workspace resolver to find OSGi bundles managed by Ivy in the workspace * NEW: Support for storing credentials securely Do you vote for the release of these binaries? -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
[VOTE] Apache IvyDE 2.3.0-rc1 release
I have built a release candidate 2.3.0-rc1 for Apache IvyDE. The tag is here: https://git1-us-west.apache.org/repos/asf?p=ant-ivyde.git;a=commit;h=refs/tags/2.3.0-rc1 You can download the distribution from this URL: https://dist.apache.org/repos/dist/dev/ant/ivyde/2.3.0-rc1 The Eclipse p2 repository is there: https://dist.apache.org/repos/dist/dev/ant/ivyde/updatesite/ivyde-2.3.0.rc1-201806132023-RELEASE/ This release consists of the following changes: * FIX: xml bomb in workspace causes hang in Ivy code during Search or Synchronize operations (https://issues.apache.org/jira/browse/IVYDE-354) * FIX: Deadlock in classpath container (https://issues.apache.org/jira/browse/IVYDE-361) * FIX: Typo in IvyResolveJob (https://issues.apache.org/jira/browse/IVYDE-362) * FIX: User-selected configurations not checked in the viewer (https://issues.apache.org/jira/browse/IVYDE-378) * FIX: Fix ClassCastException (https://issues.apache.org/jira/browse/IVYDE-386) * NEW: Support for OSGi 'Bundle-Classpath' directive * NEW: Basic support for the workspace resolver to find OSGi bundles managed by Ivy in the workspace * NEW: Support for storing credentials securely Do you vote for the release of these binaries? -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Proposing Apache IvyDE release
I'm in the process of releasing Apache IvyDE Eclipse plugin. As I go along in the release process, I'm updating the (outdated) build/release process. Once the binaries are built, I'll send out a mail for voting on the release. Following the recent convention of Ivy release, I am planning to call this release 2.3.0-rc1. -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
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
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: AntUnit Bug Causing Jenkins Failures
Sounds fine to me. -Jaikiran On 04/06/18 1:08 PM, Stefan Bodewig wrote: Hi all one of the recurring issues that make Jenkins builds fail is a thread-safety bug in AntUnit's log capturing code. This is supposed to be fixed in AntUnit's master branch. I propose to build an alpha version of AntUnit and push that to Ant's lib/optional - and then monitor Jenkins for a while validating the fix. And if it seems to work, cut a new AntUnit release. This would break build jobs that try to populate lib/optional from existing repos (either via fetch.xml or Ivy or whatever) until the next AntUnit release has been published. I am not aware of any such CI job but thought it would be good to ask before going forward. Stefan - 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
Re: InputHandler and end-of-stream
I missed this mail previously. Comments inline. >> Hi >> while reviewing some changes I realized DefaultInputHandler and >> SecureInputHandler may create unexpected outcomes if System.in or >> System.console() signal an end-of-stream and thus readLine/readPassword >> return null. >> The former will create an InputRequest with a null getInput() result >> which may come unexpected, the later handler will cause an NPE. So far >> this NPE would be swallowed (and still will be in 1.9.x) where >> DefaultInputHandler is invoked as fallback, after my latest changes to >> master it would bubble up, hence my question. >> Should we add explicit null guards? I think we should. >>I'm not really sure if/when such an >> end-of-stream may occur. If so, what would be the outcome? Handle a null >> input like an empty input and maybe fall back to the default value? Given that the null return value happens when the stream, from which we are reading, has ended earlier than expected, IMO we should consider it an error case and throw a more legible exception instead of falling back to a default value or considering it an empty input. -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: ClassLoaders in JUnit Launcher Task
On 03/06/18 3:13 PM, Jaikiran Pai wrote: I have now added a section in the junitlauncher task's manual The section's titled "Using the classpath element to include test engines". -Jaikiran to include an example which shows how to setup the classpath element to include thetestengines. The document isn't live yet but can be found in its raw form here[1]. I'm not 100% sure if this is what you were after, so feel free to reply with details if there's something else you are looking for. [1] https://raw.githubusercontent.com/apache/ant/master/manual/Tasks/junitlauncher.html -Jaikiran On 02/06/18 8:39 AM, Jaikiran Pai wrote: HelloLucas, On 01/06/18 10:46 PM, Lucas Bullen wrote: However, when attempting to do this I run into an issue with ClassLoaders. JUnitLauncherTask.execute() [2] sets the thread's ClassLoader to its own or to an AntClassLoader, both of which do not contain the junit TestEngine's Which test engine are you using and where are the jars for those located? The vintage and the jupiter test engines (part of JUnit 5) or any test engine for that matter, can be placed in the ANT_HOME/lib directory and they should be picked up. Or you can pass the -lib option while launching Ant to pass the location of those jars. These methods have been noted in the documentation of the task[1] Our previous way of getting around this was to create our own ClassLoader with the required TestEngines and set this to the current thread's ClassLoader to ensure that the TestEngines are found [4]. This technique no longer works for the JUnitLauncherTask as it resets the ClassLoader right before executing the tests. Does anyone have a suggestion on how to resolve this issue? The way JUnit 5 works, it uses the thread context classloader to find the test engines (and even test cases). That's why the JUnitLauncherTask sets it up in a manner that the right classloader is setup before executing the tests. I looked at the customer classloader you pointed to, in your footnotes. How was that being setup in the Ant build, previously? Overall, if I understand your question correctly - you do not want to add the *test engines* to the ANT_HOME/lib and neither do you want to pass the -lib option while launching Ant and instead want to define a classpath in your build file and use that classpath for finding the test engines? If that's the case, then yes it's currently a limitation (one that which Stefan had rightly brought up very early in the dev cycle of this task). I do plan to tackle this in a better way, but given the complexity involved with classloaders (both due to the nature of JUnit 5 and Ant itself) and the fact that I lost focus on this task for a bit, I haven't been able to come up with a solution. I'll look more into this in the upcoming days and see how we can improve this. If I misunderstood your use case, please do let us know. [1] https://ant.apache.org/manual/Tasks/junitlauncher.html -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: ClassLoaders in JUnit Launcher Task
I have now added a section in the junitlauncher task's manual to include an example which shows how to setup the classpath element to include thetestengines. The document isn't live yet but can be found in its raw form here[1]. I'm not 100% sure if this is what you were after, so feel free to reply with details if there's something else you are looking for. [1] https://raw.githubusercontent.com/apache/ant/master/manual/Tasks/junitlauncher.html -Jaikiran On 02/06/18 8:39 AM, Jaikiran Pai wrote: HelloLucas, On 01/06/18 10:46 PM, Lucas Bullen wrote: However, when attempting to do this I run into an issue with ClassLoaders. JUnitLauncherTask.execute() [2] sets the thread's ClassLoader to its own or to an AntClassLoader, both of which do not contain the junit TestEngine's Which test engine are you using and where are the jars for those located? The vintage and the jupiter test engines (part of JUnit 5) or any test engine for that matter, can be placed in the ANT_HOME/lib directory and they should be picked up. Or you can pass the -lib option while launching Ant to pass the location of those jars. These methods have been noted in the documentation of the task[1] Our previous way of getting around this was to create our own ClassLoader with the required TestEngines and set this to the current thread's ClassLoader to ensure that the TestEngines are found [4]. This technique no longer works for the JUnitLauncherTask as it resets the ClassLoader right before executing the tests. Does anyone have a suggestion on how to resolve this issue? The way JUnit 5 works, it uses the thread context classloader to find the test engines (and even test cases). That's why the JUnitLauncherTask sets it up in a manner that the right classloader is setup before executing the tests. I looked at the customer classloader you pointed to, in your footnotes. How was that being setup in the Ant build, previously? Overall, if I understand your question correctly - you do not want to add the *test engines* to the ANT_HOME/lib and neither do you want to pass the -lib option while launching Ant and instead want to define a classpath in your build file and use that classpath for finding the test engines? If that's the case, then yes it's currently a limitation (one that which Stefan had rightly brought up very early in the dev cycle of this task). I do plan to tackle this in a better way, but given the complexity involved with classloaders (both due to the nature of JUnit 5 and Ant itself) and the fact that I lost focus on this task for a bit, I haven't been able to come up with a solution. I'll look more into this in the upcoming days and see how we can improve this. If I misunderstood your use case, please do let us know. [1] https://ant.apache.org/manual/Tasks/junitlauncher.html -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: ClassLoaders in JUnit Launcher Task
HelloLucas, On 01/06/18 10:46 PM, Lucas Bullen wrote: However, when attempting to do this I run into an issue with ClassLoaders. JUnitLauncherTask.execute() [2] sets the thread's ClassLoader to its own or to an AntClassLoader, both of which do not contain the junit TestEngine's Which test engine are you using and where are the jars for those located? The vintage and the jupiter test engines (part of JUnit 5) or any test engine for that matter, can be placed in the ANT_HOME/lib directory and they should be picked up. Or you can pass the -lib option while launching Ant to pass the location of those jars. These methods have been noted in the documentation of the task[1] Our previous way of getting around this was to create our own ClassLoader with the required TestEngines and set this to the current thread's ClassLoader to ensure that the TestEngines are found [4]. This technique no longer works for the JUnitLauncherTask as it resets the ClassLoader right before executing the tests. Does anyone have a suggestion on how to resolve this issue? The way JUnit 5 works, it uses the thread context classloader to find the test engines (and even test cases). That's why the JUnitLauncherTask sets it up in a manner that the right classloader is setup before executing the tests. I looked at the customer classloader you pointed to, in your footnotes. How was that being setup in the Ant build, previously? Overall, if I understand your question correctly - you do not want to add the *test engines* to the ANT_HOME/lib and neither do you want to pass the -lib option while launching Ant and instead want to define a classpath in your build file and use that classpath for finding the test engines? If that's the case, then yes it's currently a limitation (one that which Stefan had rightly brought up very early in the dev cycle of this task). I do plan to tackle this in a better way, but given the complexity involved with classloaders (both due to the nature of JUnit 5 and Ant itself) and the fact that I lost focus on this task for a bit, I haven't been able to come up with a solution. I'll look more into this in the upcoming days and see how we can improve this. If I misunderstood your use case, please do let us know. [1] https://ant.apache.org/manual/Tasks/junitlauncher.html -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [1/2] ant git commit: Deprecate CollectionUtils and Enumerations; reduce explicit use of Enumeration
If your objection is that I claimed that these qualify as "most of the cases" - I really don't know what else to say then. The original commit which did this change is this[1]. I haven't reviewed it fully, but the very first few changes that are done are these [2] [3] [4] [5][6]. Of course, there's a subsequent commit which then uses a different new util, instead of just using the existing iterator/enumeration. Speaking of the subsequent commit, it still doesn't undo the (IMO unnecessary) change that was done to some of the code (take a look at ArgumentProcessorRegistry.java for example). Even if these don't fall under "most of the cases", why even change these places? I'm sure you would know this - the Enumeration or APIs that you refactored aren't even deprecated in Java version 10. Anyway, I'm really getting tired of these back and forth arguments on refactoring. The reason I get involved in certain open source projects is to get a chance to work with like minded developers and learn something out of it and not to go wage a war on which coding style is better or try and be critical of other committers' commits. Unfortunately, in the recent past, this has reached a state where I have ended up spending more time being critical of changes that have gone in, than actually adding much code of value. As much as I try to stay away from reviews or checking the commit logs, I just keep going back to them. I don't want to end up being a grumpy guy criticizing the commits. I'm just going to take a break from this for some days and be a regular user and come back and see if I still enjoy contributing. [1] https://github.com/apache/ant/commit/070c3bc86f85e8f01cb624fe50ae82f0d11171b2 [2] https://github.com/apache/ant/commit/070c3bc86f85e8f01cb624fe50ae82f0d11171b2#diff-21eb59eaf9f2b5d0b487aeb5e5022ccdL746 [3] https://github.com/apache/ant/commit/070c3bc86f85e8f01cb624fe50ae82f0d11171b2#diff-21eb59eaf9f2b5d0b487aeb5e5022ccdL834 [4] https://github.com/apache/ant/commit/070c3bc86f85e8f01cb624fe50ae82f0d11171b2#diff-21eb59eaf9f2b5d0b487aeb5e5022ccdL888 [5] https://github.com/apache/ant/commit/070c3bc86f85e8f01cb624fe50ae82f0d11171b2#diff-21eb59eaf9f2b5d0b487aeb5e5022ccdL1359 [6] https://github.com/apache/ant/commit/070c3bc86f85e8f01cb624fe50ae82f0d11171b2#diff-b98a3d2097d6a9b5d7e0fc2eac033f24L348 -Jaikiran On 18/05/18 11:15 AM, Gintautas Grigelionis wrote: I'm not quite sure that what you say was true "in most of the cases". Gintas 2018-05-18 6:52 GMT+02:00 Jaikiran Pai : To be honest, I don't think this deprecation/conversion change is good(including this recent commit whichintroduces a StreamUtils.enumerationAsStream(...)) To give you an example, the code that was previously present would (in most of the cases) get hold of an enumeration and would iterate over it and during that iteration would runcertain logic. With the changes that went in (which again is a bulk change!) the code now gets hold of an enumeration and instead of just getting on the business of iterating and running certain logic, instead now passes this enumeration aroundto convert it into some other form (thus additional code plus additional objects allocated in the process), all this to iterate over it and run some logic on it - all of which was already possible with the enumeration that was already available. -Jaikiran On 18/05/18 12:22 AM, Gintautas Grigelionis wrote: Thanks for reviewing, I hope Spliterators will do a better job. Gintas 2018-05-17 8:37 GMT+02:00 Jaikiran Pai : I agree. Especially when it's being done on something like for archive entries which can betoo many depending on the archive that is being dealt with. -Jaikiran On 17/05/18 12:04 PM, Maarten Coene wrote: Converting an Enumeration to a List just for iterating it doesn't seem performance and memory wise a good idea to me. Maarten Van: "gin...@apache.org" Aan: notificati...@ant.apache.org Verzonden: woensdag 16 mei 19:13 2018 Onderwerp: [1/2] ant git commit: Deprecate CollectionUtils and Enumerations; reduce explicit use of Enumeration Repository: ant Updated Branches: refs/heads/master ac35c0014 -> 070c3bc86 http://git-wip-us.apache.org/repos/asf/ant/blob/070c3bc8/src /main/org/apache/tools/ant/types/ZipScanner.java -- diff --git a/src/main/org/apache/tools/ant/types/ZipScanner.java b/src/main/org/apache/tools/ant/types/ZipScanner.java index a3df040..5667159 100644 --- a/src/main/org/apache/tools/ant/types/ZipScanner.java +++ b/src/main/org/apache/tools/ant/types/ZipScanner.java @@ -20,7 +20,7 @@ package org.apache.tools.ant.types; import java.io.File; import java.io.IOException; -import java.util.Enumeration; +import java.util.Collections; import java.util.Map; import java.u
Re: [1/2] ant git commit: Deprecate CollectionUtils and Enumerations; reduce explicit use of Enumeration
To be honest, I don't think this deprecation/conversion change is
good(including this recent commit whichintroduces a
StreamUtils.enumerationAsStream(...))
To give you an example, the code that was previously present would (in
most of the cases) get hold of an enumeration and would iterate over it
and during that iteration would runcertain logic. With the changes that
went in (which again is a bulk change!) the code now gets hold of an
enumeration and instead of just getting on the business of iterating and
running certain logic, instead now passes this enumeration aroundto
convert it into some other form (thus additional code plus additional
objects allocated in the process), all this to iterate over it and run
some logic on it - all of which was already possible with the
enumeration that was already available.
-Jaikiran
On 18/05/18 12:22 AM, Gintautas Grigelionis wrote:
Thanks for reviewing, I hope Spliterators will do a better job.
Gintas
2018-05-17 8:37 GMT+02:00 Jaikiran Pai :
I agree. Especially when it's being done on something like for archive
entries which can betoo many depending on the archive that is being dealt
with.
-Jaikiran
On 17/05/18 12:04 PM, Maarten Coene wrote:
Converting an Enumeration to a List just for iterating it doesn't seem
performance and memory wise a good idea to me.
Maarten
Van: "gin...@apache.org"
Aan: notificati...@ant.apache.org
Verzonden: woensdag 16 mei 19:13 2018
Onderwerp: [1/2] ant git commit: Deprecate CollectionUtils and
Enumerations; reduce explicit use of Enumeration
Repository: ant
Updated Branches:
refs/heads/master ac35c0014 -> 070c3bc86
http://git-wip-us.apache.org/repos/asf/ant/blob/070c3bc8/src
/main/org/apache/tools/ant/types/ZipScanner.java
--
diff --git a/src/main/org/apache/tools/ant/types/ZipScanner.java
b/src/main/org/apache/tools/ant/types/ZipScanner.java
index a3df040..5667159 100644
--- a/src/main/org/apache/tools/ant/types/ZipScanner.java
+++ b/src/main/org/apache/tools/ant/types/ZipScanner.java
@@ -20,7 +20,7 @@ package org.apache.tools.ant.types;
import java.io.File;
import java.io.IOException;
-import java.util.Enumeration;
+import java.util.Collections;
import java.util.Map;
import java.util.zip.ZipException;
@@ -62,10 +62,7 @@ public class ZipScanner extends ArchiveScanner {
"Only file provider resources are supported"));
try (ZipFile zf = new ZipFile(srcFile, encoding)) {
-
-Enumeration e = zf.getEntries();
-while (e.hasMoreElements()) {
-ZipEntry entry = e.nextElement();
+for (ZipEntry entry : Collections.list(zf.getEntries())) {
Resource r = new ZipResource(srcFile, encoding, entry);
String name = entry.getName();
if (entry.isDirectory()) {
-
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
Re: [1/2] ant git commit: Deprecate CollectionUtils and Enumerations; reduce explicit use of Enumeration
I agree. Especially when it's being done on something like for archive
entries which can betoo many depending on the archive that is being
dealt with.
-Jaikiran
On 17/05/18 12:04 PM, Maarten Coene wrote:
Converting an Enumeration to a List just for iterating it doesn't seem
performance and memory wise a good idea to me.
Maarten
Van: "gin...@apache.org"
Aan: notificati...@ant.apache.org
Verzonden: woensdag 16 mei 19:13 2018
Onderwerp: [1/2] ant git commit: Deprecate CollectionUtils and Enumerations;
reduce explicit use of Enumeration
Repository: ant
Updated Branches:
refs/heads/master ac35c0014 -> 070c3bc86
http://git-wip-us.apache.org/repos/asf/ant/blob/070c3bc8/src/main/org/apache/tools/ant/types/ZipScanner.java
--
diff --git a/src/main/org/apache/tools/ant/types/ZipScanner.java
b/src/main/org/apache/tools/ant/types/ZipScanner.java
index a3df040..5667159 100644
--- a/src/main/org/apache/tools/ant/types/ZipScanner.java
+++ b/src/main/org/apache/tools/ant/types/ZipScanner.java
@@ -20,7 +20,7 @@ package org.apache.tools.ant.types;
import java.io.File;
import java.io.IOException;
-import java.util.Enumeration;
+import java.util.Collections;
import java.util.Map;
import java.util.zip.ZipException;
@@ -62,10 +62,7 @@ public class ZipScanner extends ArchiveScanner {
"Only file provider resources are supported"));
try (ZipFile zf = new ZipFile(srcFile, encoding)) {
-
- Enumeration e = zf.getEntries();
- while (e.hasMoreElements()) {
- ZipEntry entry = e.nextElement();
+ for (ZipEntry entry : Collections.list(zf.getEntries())) {
Resource r = new ZipResource(srcFile, encoding, entry);
String name = entry.getName();
if (entry.isDirectory()) {
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
[GitHub] ant-antlibs-antunit issue #1: Avoid potential thread safety issues in LogCap...
Github user jaikiran commented on the issue: https://github.com/apache/ant-antlibs-antunit/pull/1 Thank you. Merged. --- - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
[GitHub] ant-antlibs-antunit pull request #1: Avoid potential thread safety issues in...
GitHub user jaikiran opened a pull request: https://github.com/apache/ant-antlibs-antunit/pull/1 Avoid potential thread safety issues in LogCapturer This commit is prompted by the exception I saw in one of the Ant Jenkins jobs which failed with: ``` /home/jenkins/jenkins-slave/workspace/Ant-Build-Matrix-master-Linux/OS/xenial/jdk/JDK 1.8 (latest)/src/tests/antunit/taskdefs/exec/exec-test.xml:528: java.lang.NullPointerException at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:109) at org.apache.tools.ant.TaskAdapter.execute(TaskAdapter.java:155) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:99) at org.apache.tools.ant.Task.perform(Task.java:350) at java.util.Vector.forEach(Vector.java:1275) at org.apache.tools.ant.taskdefs.Sequential.execute(Sequential.java:67) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:99) at org.apache.tools.ant.Task.perform(Task.java:350) at org.apache.tools.ant.taskdefs.MacroInstance.execute(MacroInstance.java:393) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:99) at org.apache.tools.ant.Task.perform(Task.java:350) at org.apache.tools.ant.Target.execute(Target.java:449) at org.apache.tools.ant.Target.performTasks(Target.java:470) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1392) at org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:36) at org.apache.tools.ant.Project.executeTargets(Project.java:1253) at org.apache.ant.antunit.AntUnitScriptRunner.runTarget(AntUnitScriptRunner.java:224) at org.apache.ant.antunit.AntUnitScriptRunner.runSuite(AntUnitScriptRunner.java:303) at org.apache.ant.antunit.AntUnit.doFile(AntUnit.java:268) at org.apache.ant.antunit.AntUnit.doResourceCollection(AntUnit.java:247) at org.apache.ant.antunit.AntUnit.execute(AntUnit.java:218) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:99) at org.apache.tools.ant.Task.perform(Task.java:350) at org.apache.tools.ant.Target.execute(Target.java:449) at org.apache.tools.ant.Target.performTasks(Target.java:470) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1392) at org.apache.tools.ant.Project.executeTarget(Project.java:1363) at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) at org.apache.tools.ant.Project.executeTargets(Project.java:1253) at org.apache.tools.ant.Main.runBuild(Main.java:845) at org.apache.tools.ant.Main.startAnt(Main.java:228) at org.apache.tools.ant.launch.Launcher.run(Launcher.java:284) at org.apache.tools.ant.launch.Launcher.main(Launcher.java:101) Caused by: java.lang.NullPointerException at java.util.LinkedList$ListItr.next(LinkedList.java:893) at org.apache.ant.antunit.LogCapturer.getLog(LogCapturer.java:178) at org.apache.ant.antunit.LogCapturer.getInfoLog(LogCapturer.java:114) at org.apache.ant.antunit.LogContains.eval(LogContains.java:81) at org.apache.ant.antunit.AssertTask.execute(AssertTask.java:71) at sun.reflect.GeneratedMethodAccessor42.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:99) ... 48 more ``` That specific race condition itself is somewhat
Re: [GitHub] ant pull request #:
No problem. That change to WHATSNEW is fine, I don't mind. -Jaikiran On 13/05/18 1:03 PM, Gintautas Grigelionis wrote: Thanks, great work! I hope you don't mind me taking the liberty to adjust WHATSNEW. Gintas 2018-05-13 6:01 GMT+02:00 Jaikiran Pai : I did plan to addit yesterday, but my local tests did not trigger the package-info constant pool entry for some reason. So I decided to not rush it in and spend some time to get the test right, to make sure it works fine. I'll add it in either tonight or tomorrow once I get to see what's going on. -Jaikiran On 12/05/18 9:19 PM, twogee wrote: Github user twogee commented on the pull request: https://github.com/apache/ant/commit/d0f9c2e121e2b3a18b6 79705c2f2164426e7e6fb#commitcomment-28953469 In src/main/org/apache/tools/ant/taskdefs/optional/depend/const antpool/ConstantPoolEntry.java: In src/main/org/apache/tools/ant/taskdefs/optional/depend/constantpool/ConstantPoolEntry.java on line 77: Please add 20 (package), too --- - 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 - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [GitHub] ant pull request #:
I did plan to addit yesterday, but my local tests did not trigger the package-info constant pool entry for some reason. So I decided to not rush it in and spend some time to get the test right, to make sure it works fine. I'll add it in either tonight or tomorrow once I get to see what's going on. -Jaikiran On 12/05/18 9:19 PM, twogee wrote: Github user twogee commented on the pull request: https://github.com/apache/ant/commit/d0f9c2e121e2b3a18b679705c2f2164426e7e6fb#commitcomment-28953469 In src/main/org/apache/tools/ant/taskdefs/optional/depend/constantpool/ConstantPoolEntry.java: In src/main/org/apache/tools/ant/taskdefs/optional/depend/constantpool/ConstantPoolEntry.java on line 77: Please add 20 (package), too --- - 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
Re: ant depends task fails for JDK10 module-info.class
On 12/05/18 8:29 PM, Simon IJskes wrote: I went ahead and pushed a commit[1] to fix this. We have our nightly Jenkins job which generates a nightly build. So if you would like to test it, you can pick up a distribution which contains this commit, whenever the next job runs. The artifact should be available here[2]. [1] https://github.com/apache/ant/commit/d0f9c2e121e2b3a18b679705c2f2164426e7e6fb [2] https://builds.apache.org/job/Ant_Nightly/lastSuccessfulBuild/artifact/distribution/ it works! Glad to hear that :) -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: ant depends task fails for JDK10 module-info.class
I went ahead and pushed a commit[1] to fix this. We have our nightly Jenkins job which generates a nightly build. So if you would like to test it, you can pick up a distribution which contains this commit, whenever the next job runs. The artifact should be available here[2]. [1] https://github.com/apache/ant/commit/d0f9c2e121e2b3a18b679705c2f2164426e7e6fb [2] https://builds.apache.org/job/Ant_Nightly/lastSuccessfulBuild/artifact/distribution/ -Jaikiran On 12/05/18 5:30 PM, Jaikiran Pai wrote: Looks like a bug. Can you file a bug in the Ant bugzilla? I can take a look at it later tonight. -Jaikiran On 12/05/18 4:45 PM, Simon IJskes wrote: Hi, Just checking if this bug is known? I could not find it in bugzilla. https://issues.apache.org/jira/browse/NETBEANS-781 Groeten, Simon - 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
Re: ant depends task fails for JDK10 module-info.class
Looks like a bug. Can you file a bug in the Ant bugzilla? I can take a look at it later tonight. -Jaikiran On 12/05/18 4:45 PM, Simon IJskes wrote: Hi, Just checking if this bug is known? I could not find it in bugzilla. https://issues.apache.org/jira/browse/NETBEANS-781 Groeten, Simon - 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
Re: ant git commit: Inline buildfile names, make search easier
On 30/04/18 12:52 PM, Gintautas Grigelionis wrote: My apologies for offending anyone; just one last silly question: why uniformity is not a requirement? I think it has already been explained in the other thread why it's not a necessity for a project as large and as old as this one, especially when the changes aren't solving anything. Plus, I believe you even agreed to it, when this was explained in that other thread. Either way, this isn't about uniformity. Take a look at this commit for example (and it's just one of the many). It was done, as you admit, because you wanted to find a particular piece of text when you run "grep configureProject". There's no level of uniformity that can solve such random requirements, unless of course the code is auto-generated to fit in these requirements. I believe that even one language that espoused TMTOWDI has moved to TIMTOWTDIBSCINABTE? Sorry, I really don't know what that means or how that relates to what we are discussing. -Jaikiran Gintas 2018-04-30 5:56 GMT+00:00 Jaikiran Pai : On 30/04/18 11:12 AM, Gintautas Grigelionis wrote: Names of buildfiles used in tests can be found by "grep configureProject"? Why is that even a requirement? I think I am just repeating myself again and again in different mails. Changes like these are random personal preferences. The fact that these are being done even after the mail discussions we recently had, indicates that the request to not do such changes have been ignored. This is going down the route of a being some kind of a personal individual hobby project. So I'm just going to stop bothering looking into these commits anymore and just stay away from them and stop sending this frustrated and rude sounding mails. -Jaikiran The point is that these names are used exactly once, and need not to be put in a field which is named inconsistently. Deviations from this rule of thumb indicate that tests are parameterized in a manner where each test has its own buildfile. Gintas 2018-04-30 4:43 GMT+00:00 Jaikiran Pai : What purpose is this change serving? -Jaikiran On 30/04/18 10:08 AM, gin...@apache.org wrote: Repository: ant Updated Branches: refs/heads/master 0add85310 -> f3dfb7779 Inline buildfile names, make search easier Project: http://git-wip-us.apache.org/repos/asf/ant/repo Commit: http://git-wip-us.apache.org/repos/asf/ant/commit/f3dfb777 Tree: http://git-wip-us.apache.org/repos/asf/ant/tree/f3dfb777 Diff: http://git-wip-us.apache.org/repos/asf/ant/diff/f3dfb777 - 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
Re: ant git commit: Inline buildfile names, make search easier
On 30/04/18 3:52 PM, Gintautas Grigelionis wrote: 2018-04-30 9:55 GMT+00:00 Stefan Bodewig : On 2018-04-30, Gintautas Grigelionis wrote: My apologies for offending anyone; just one last silly question: why uniformity is not a requirement? Who's uniformity do you pick? There are so many choices that only depend on taste. assertEquals(x, y) vs assertThat(y, equalTo(x)) amd many many small nuances that we all don't need to agree on, as long as we understand what the code means and does and we accept to not change code just because it doesn't conform to our own choices. assertThat(object, matcher) is easier to parameterize, see MakeUrlTest. And regarding parameterization, I have found at least three cases of copy-paste errors where two supposedly different test cases were, in fact, identical. The assertEquals vs assertThat was an example of different ways a certain thing can be implemented. I hope you do realize that what we are discussing in this thread (and others) is much more broader than finding copy/paste errors due to usage of one API over other. -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: ant git commit: Inline buildfile names, make search easier
On 30/04/18 11:12 AM, Gintautas Grigelionis wrote: Names of buildfiles used in tests can be found by "grep configureProject"? Why is that even a requirement? I think I am just repeating myself again and again in different mails. Changes like these are random personal preferences. The fact that these are being done even after the mail discussions we recently had, indicates that the request to not do such changes have been ignored. This is going down the route of a being some kind of a personal individual hobby project. So I'm just going to stop bothering looking into these commits anymore and just stay away from them and stop sending this frustrated and rude sounding mails. -Jaikiran The point is that these names are used exactly once, and need not to be put in a field which is named inconsistently. Deviations from this rule of thumb indicate that tests are parameterized in a manner where each test has its own buildfile. Gintas 2018-04-30 4:43 GMT+00:00 Jaikiran Pai : What purpose is this change serving? -Jaikiran On 30/04/18 10:08 AM, gin...@apache.org wrote: Repository: ant Updated Branches: refs/heads/master 0add85310 -> f3dfb7779 Inline buildfile names, make search easier Project: http://git-wip-us.apache.org/repos/asf/ant/repo Commit: http://git-wip-us.apache.org/repos/asf/ant/commit/f3dfb777 Tree: http://git-wip-us.apache.org/repos/asf/ant/tree/f3dfb777 Diff: http://git-wip-us.apache.org/repos/asf/ant/diff/f3dfb777 - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: ant git commit: Inline buildfile names, make search easier
What purpose is this change serving?
-Jaikiran
On 30/04/18 10:08 AM, gin...@apache.org wrote:
Repository: ant
Updated Branches:
refs/heads/master 0add85310 -> f3dfb7779
Inline buildfile names, make search easier
Project: http://git-wip-us.apache.org/repos/asf/ant/repo
Commit: http://git-wip-us.apache.org/repos/asf/ant/commit/f3dfb777
Tree: http://git-wip-us.apache.org/repos/asf/ant/tree/f3dfb777
Diff: http://git-wip-us.apache.org/repos/asf/ant/diff/f3dfb777
Branch: refs/heads/master
Commit: f3dfb7779a528439a390ab09383cd8cb6b7e8307
Parents: 0add853
Author: Gintas Grigelionis
Authored: Mon Apr 30 06:38:27 2018 +0200
Committer: Gintas Grigelionis
Committed: Mon Apr 30 06:38:27 2018 +0200
--
.../apache/tools/ant/taskdefs/ExecTaskTest.java | 4 +---
.../apache/tools/ant/taskdefs/JavadocTest.java | 6 +-
.../apache/tools/ant/taskdefs/ParallelTest.java | 5 +
.../tools/ant/taskdefs/PathConvertTest.java | 4 +---
.../tools/ant/taskdefs/RmicAdvancedTest.java| 4 +---
.../apache/tools/ant/taskdefs/SleepTest.java| 3 +--
.../org/apache/tools/ant/taskdefs/WarTest.java | 4 +---
.../tools/ant/taskdefs/optional/ANTLRTest.java | 4 +---
.../taskdefs/optional/EchoPropertiesTest.java | 21 ++--
.../tools/ant/taskdefs/optional/JavahTest.java | 4 +---
.../tools/ant/taskdefs/optional/JspcTest.java | 4 +---
.../ant/taskdefs/optional/Native2AsciiTest.java | 5 +
.../taskdefs/optional/ReplaceRegExpTest.java| 3 +--
.../taskdefs/optional/RhinoReferenceTest.java | 3 +--
.../taskdefs/optional/SchemaValidateTest.java | 7 +--
.../optional/XmlValidateCatalogTest.java| 7 +--
.../ant/taskdefs/optional/XmlValidateTest.java | 7 +--
.../taskdefs/optional/depend/DependTest.java| 5 +
.../ant/taskdefs/optional/image/ImageTest.java | 3 +--
.../junit/XMLFormatterWithCDATAOnSystemOut.java | 3 +--
20 files changed, 25 insertions(+), 81 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/ant/blob/f3dfb777/src/tests/junit/org/apache/tools/ant/taskdefs/ExecTaskTest.java
--
diff --git a/src/tests/junit/org/apache/tools/ant/taskdefs/ExecTaskTest.java
b/src/tests/junit/org/apache/tools/ant/taskdefs/ExecTaskTest.java
index fd92ded..cf30955 100644
--- a/src/tests/junit/org/apache/tools/ant/taskdefs/ExecTaskTest.java
+++ b/src/tests/junit/org/apache/tools/ant/taskdefs/ExecTaskTest.java
@@ -44,8 +44,6 @@ public class ExecTaskTest {
@Rule
public BuildFileRule buildRule = new BuildFileRule();
-private static final String BUILD_PATH = "src/etc/testcases/taskdefs/exec/";
-private static final String BUILD_FILE = BUILD_PATH + "exec.xml";
private static final int TIME_TO_WAIT = 1;
/** maximum time allowed for the build in milliseconds */
private static final int MAX_BUILD_TIME = 6000;
@@ -60,7 +58,7 @@ public class ExecTaskTest {
@Before
public void setUp() {
-buildRule.configureProject(BUILD_FILE);
+buildRule.configureProject("src/etc/testcases/taskdefs/exec/exec.xml");
}
@Test
http://git-wip-us.apache.org/repos/asf/ant/blob/f3dfb777/src/tests/junit/org/apache/tools/ant/taskdefs/JavadocTest.java
--
diff --git a/src/tests/junit/org/apache/tools/ant/taskdefs/JavadocTest.java
b/src/tests/junit/org/apache/tools/ant/taskdefs/JavadocTest.java
index f7a287d..cae8620 100644
--- a/src/tests/junit/org/apache/tools/ant/taskdefs/JavadocTest.java
+++ b/src/tests/junit/org/apache/tools/ant/taskdefs/JavadocTest.java
@@ -28,13 +28,9 @@ public class JavadocTest {
@Rule
public final BuildFileRule buildRule = new BuildFileRule();
-private static final String BUILD_PATH = "src/etc/testcases/taskdefs/javadoc/";
-private static final String BUILD_FILENAME = "javadoc.xml";
-private static final String BUILD_FILE = BUILD_PATH + BUILD_FILENAME;
-
@Before
public void setUp() {
-buildRule.configureProject(BUILD_FILE);
+
buildRule.configureProject("src/etc/testcases/taskdefs/javadoc/javadoc.xml");
}
// PR 38370
http://git-wip-us.apache.org/repos/asf/ant/blob/f3dfb777/src/tests/junit/org/apache/tools/ant/taskdefs/ParallelTest.java
--
diff --git a/src/tests/junit/org/apache/tools/ant/taskdefs/ParallelTest.java
b/src/tests/junit/org/apache/tools/ant/taskdefs/ParallelTest.java
index eba49c9..c08564e 100644
--- a/src/tests/junit/org/apache/tools/ant/taskdefs/ParallelTest.java
+++ b/src/tests/junit/org/apache/tools/ant/taskdefs/ParallelTest.java
@@ -52,14 +52,11 @@ public class Par
Re: [Announce] Release of Apache Ivy 2.5.0-rc1
Thank you Nicolas for running this release. -Jaikiran On 22/04/18 11:24 PM, Nicolas Lalevée wrote: The Apache Ivy project is pleased to announce its 2.5.0-rc1 release. Apache Ivy is a tool for managing (recording, tracking, resolving and reporting) project dependencies, characterized by flexibility, configurability, and tight integration with Apache Ant. Key features of this 2.5.0-rc1 release are * The minimum runtime Java version required is now Java 7 * Ivy now uses BouncyCastle OpenPGP API 1.59. Due to the non backward compatibility of that library, earlier versions are not supported. * Ivy now uses HttpComponents HttpClient 4.5.x version with HTTP backed resolvers. Users are expected to have this version of the library (and its dependencies) in their runtime classpath if they want to use such resolvers. The previous (similarly named but not the same) commons-httpclient library is no longer used or supported. (IVY-1563) As a release candidate version, we strongly encourage the use of this version for testing and validation. Issues should be reported to: https://issues.apache.org/jira/browse/IVY <https://issues.apache.org/jira/browse/IVY> Download the 2.5.0-rc1 release at: http://ant.apache.org/ivy/download.cgi <http://ant.apache.org/ivy/download.cgi> More information can be found on the Ivy website: http://ant.apache.org/ivy/ <http://ant.apache.org/ivy/> Regards, Nicolas Lalevée - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Ant JUnit tests
Like discussed in the other thread, I don't understand what's wrong with setting the expected properties in the IDE itself (like the "ant.home"). IDEs provide these configurations/settings for reasons like these. What would it achieve by virtually disabling these tests, in IDE, by adding those assumptions? -Jaikiran On 20/04/18 10:39 AM, Gintautas Grigelionis wrote: I am refactoring Ant JUnit tests with a goal to make them more "IDE-friendly". I found several tests that are implictly dependent on ant.home property being set. In these cases, the test should be prevented from execution by adding an assumption; however, perhaps there might be a suitable default, like basedir + "/bootstrap" or some other location that might be suggested in, say, javadoc? Thanks, Gintas - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Include ANT_HOME location in "ant -version" ?
In context of this[1] and many similar questions/confusion previously, I am wondering if our "ant -version" output should even include, a line in the output, the location which is used as ANT_HOME? That will probably make it clearer and easy to understand where it's being printed from. Any thoughts? [1] https://www.mail-archive.com/user@ant.apache.org/msg42757.html -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
JUnit 5 tests incorrectly picked up during Ant junit tests
It indeed looks like a build exclusion that I might have missed. I will take a look at this and fix it. -Jaikiran On 15/04/18 9:35 PM, Stefan Bodewig wrote: On 2018-04-15, Gintautas Grigelionis wrote: By the looks of it, JUnit 5 runner tests need an assumption check, too. Not sure why, but I may again be missing something. Please have a look at TeamCity tests at JetBrains. They start with a clean directory, then run ant -Ddest=optional -f fetch.xml, then ./build.sh test, and fail with java.lang.Exception: No runnable methods This more looks as if we need an extra dependency for the tests and should exclude the test class if no engine is present, but I'm not sure. Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: ant git commit: More isEmpty()
On 11/04/18 1:27 PM, Stefan Bodewig wrote:
On 2018-04-06, wrote:
http://git-wip-us.apache.org/repos/asf/ant/blob/c3b91f90/src/main/org/apache/tools/ant/types/ArchiveFileSet.java
--
diff --git a/src/main/org/apache/tools/ant/types/ArchiveFileSet.java
b/src/main/org/apache/tools/ant/types/ArchiveFileSet.java
index e4b9d12..eea603d 100644
--- a/src/main/org/apache/tools/ant/types/ArchiveFileSet.java
b/src/main/org/apache/tools/ant/types/ArchiveFileSet.java
@@ -223,7 +223,7 @@ public abstract class ArchiveFileSet extends FileSet {
*/
public void setPrefix(String prefix) {
checkArchiveAttributesAllowed();
-if (!"".equals(prefix) && !"".equals(fullpath)) {
+if (!prefix.isEmpty() && !fullpath.isEmpty()) {
throw new BuildException(ERROR_PATH_AND_PREFIX);
}
this.prefix = prefix;
@@ -250,7 +250,7 @@ public abstract class ArchiveFileSet extends FileSet {
*/
public void setFullpath(String fullpath) {
checkArchiveAttributesAllowed();
-if (!"".equals(prefix) && !"".equals(fullpath)) {
+if (!prefix.isEmpty() && !fullpath.isEmpty()) {
throw new BuildException(ERROR_PATH_AND_PREFIX);
}
this.fullpath = fullpath;
in both hunks prefix or fullpath could be null. Obviously the old code
doesn't handle this properly either. Do we want to keep assuming nobody
invokes either method with a null argument? I'm afraid we aren't really
consistent with the attribute setters dealing with null args.
I think we could probably document that passing null to such attribute
setters will lead to NullPointerException, which most likely will be the
case in a lot of places other than those that just set the incoming
value to some member variable.
-Jaikiran
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
Re: [VOTE] Ivy 2.5.0-rc1 Release
+1. Thank you Nicolas for running this release. Tested the following: - Downloaded the .tar.gz binary - Checked some random docs, that are part of the download. Looks fine. - Built some random internal projects using this downloaded version of Ivy, using Java 8. All went well. - Verified bug fixes for some random fixes that were part of this release (IVY-1540 and IVY-1577). Worked fine. - Built some internal projects using the downloaded version of Ivy, using Java 9. All went fine. -Jaikiran On 12/04/18 9:59 PM, Nicolas Lalevée wrote: I have built a release candidate for Ivy 2.5.0-rc1. The git tag of this release is: https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=tag;h=refs/tags/2.5.0-rc1 <https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=tag;h=refs/tags/2.5.0-rc1> with the sha1 887fd46f3e90016e313f7724ca259b936d30a03e The artifacts has been published to: https://dist.apache.org/repos/dist/dev/ant/ivy/2.5.0-rc1 <https://dist.apache.org/repos/dist/dev/ant/ivy/2.5.0-rc1> at revision 26310 The staging Maven repository is available there: https://repository.apache.org/content/repositories/orgapacheant-1026 <https://repository.apache.org/content/repositories/orgapacheant-1026> The Eclipse updatesite has been build there: https://dist.apache.org/repos/dist/dev/ant/ivyde/updatesite/ivy-2.5.0.cr1_20180412005306 <https://dist.apache.org/repos/dist/dev/ant/ivyde/updatesite/ivy-2.5.0.cr1_20180412005306> Do you vote for the release of these binaries? Regards, Nicolas - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Mass changes to various projects under Ant umbrella - should we be doing it?
On 10/04/18 12:27 AM, Gintautas Grigelionis wrote: 2018-04-08 16:13 GMT+00:00 Stefan Bodewig : I don't believe woking well tested code rots. Code rot is something that happends when code doesn't get adapted to changing environments or requirements. This is not the case here. I wrote earlier that I was about to review the unit tests. I was particularly unhappy about the root-property hack for an ancient deficiency in Surefire. I checked some of the mail discussions, but couldn't find any relevant details about this. Can you explain what the root-property hack is? I also don't understand how Surefire is related to our tests, which are run using the junit and ant-unit framework. If I missed some previous discussion, please pointme to it and I'll read up on that. I consider my previous commits a sort of a groundwork for refactorisation of JUnit tests. Considering the commits that have been made (even just considering only the Ant ones), I don't see how those relate to some plan to refactor JUnit tests. -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Ivy release
+1. Thanks Nicolas. -Jaikiran On Monday, April 9, 2018, Nicolas Lalevée wrote: > The last thread about a release has been stuck in the discussion about which PR, patch or Jira needed to be tackled before releasing. I suggest we just move forward with the current master. I volunteer to build a 2.5.0-rc1. > > Nicolas > > > - > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > For additional commands, e-mail: dev-h...@ant.apache.org > >
Mass changes to various projects under Ant umbrella - should we be doing it?
I don't mean to appear authoritative but I feel that these mass, never-ending changes to various projects under the Ant umbrella, related to formatting, coding style, whitespaces, syntax changes and such aren't really worth it. Especially when a lot of those changes are merely, IMO, personal preferences, to code that has been around for a long time now. It's extremely hard to do any kind of review for such changes and IMO they really don't add any value. I can understand if the changes are being done in specific section when a bug or feature involves that specific area of code, but a lot of these commits aren't of that nature. I haven't been long around in the project, to have any kind of authority on this matter, but having been involved in some other open source projects, changes like these aren't really good nor are typically considered required or accepted. Could we please reconsider whether or not we should be doing such changes? -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
[GitHub] ant-ivy issue #71: Ivy main/standalone: Patch to include 'makepom' function
Github user jaikiran commented on the issue: https://github.com/apache/ant-ivy/pull/71 @aanno, thank you for this PR. I have gone ahead and included your patch with minor modifications to upstream and also included a test along with it. I have also included your name in our release notes. Since I couldn't find your full name in your github profile, I used `aanno`, if you prefer to have your full name included in the release notes, please let me know and I'll update it accordingly. --- - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
[GitHub] ant-ivy pull request #71: Ivy main/standalone: Patch to include 'makepom' fu...
Github user jaikiran commented on a diff in the pull request:
https://github.com/apache/ant-ivy/pull/71#discussion_r177694759
--- Diff: src/java/org/apache/ivy/Main.java ---
@@ -199,6 +201,10 @@ static CommandLineParser getParser() {
new OptionBuilder("cp").arg("cp")
.description("extra classpath to use when
launching process").create())
+.addCategory("maven compatibility options")
+.addOption(new
OptionBuilder("pomfile").arg("pomfile").countArgs(false)
--- End diff --
A small suggestion - can you change this to something like:
```
new OptionBuilder("makepom").arg("pomfile")
```
---
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
[GitHub] ant-ivy pull request #71: Ivy main/standalone: Patch to include 'makepom' fu...
Github user jaikiran commented on a diff in the pull request:
https://github.com/apache/ant-ivy/pull/71#discussion_r177694862
--- Diff: src/java/org/apache/ivy/Main.java ---
@@ -199,6 +201,10 @@ static CommandLineParser getParser() {
new OptionBuilder("cp").arg("cp")
.description("extra classpath to use when
launching process").create())
+.addCategory("maven compatibility options")
+.addOption(new
OptionBuilder("pomfile").arg("pomfile").countArgs(false)
+.description("makepom as standalone
tasks").create())
--- End diff --
I think the description should be a bit more clear and state that this
generates a pom file for the resolved module.
---
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
[GitHub] ant-ivy issue #71: Ivy main/standalone: Patch to include 'makepom' function
Github user jaikiran commented on the issue: https://github.com/apache/ant-ivy/pull/71 @aanno Thank you for the patch. This mostly looks fine. I have added some review comments. Can you please also introduce a test case for this? Something that tests that these command options are recognized and the pom file does get created. There's a `MainTest` which you can refer to and add a new test method there. --- - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [ANN] Apache Ant 1.9.11 and 1.10.3 Released
Stefan, thank you for running these releases. -Jaikiran On 28/03/18 10:52 AM, Stefan Bodewig wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The Apache Ant Team is pleased to announce the releases of Apache Ant 1.9.11 and 1.10.3. Apache Ant is a Java library and command-line tool that helps building software. The Apache Ant team currently maintains two lines of development. The 1.9.x releases require Java5 at runtime and 1.10.x requires Java8 at runtime. Both lines are based off of Ant 1.9.7 and the 1.9.x releases are mostly bug fix releases while additional new features are developed for 1.10.x. We recommend using 1.10.3 unless you are required to use versions of Java prior to Java8 during the build process. Ant 1.10.3 contains a superset of 1.9.11 - with the exception of a few tasks and features that no longer work with Java8 anyway (like the apt task). Both releases are mostly bug fix releases with a few new features being added. Ant 1.10.2 introduced a number of regressions that are now fixed in 1.10.3. Ant 1.10.3 introduces initial support for JUnit5 in the form of the junitlauncher task. The new task is fully functional but currently lacks a few features like forking a new JVM for tests which will be added in upcoming releases. Source and binary distributions are available for download from the Apache Ant download site: http://ant.apache.org/bindownload.cgi http://ant.apache.org/srcdownload.cgi When downloading, please verify signatures using the KEYS file available at the above location when downloading the release. Changes in 1.10.3 include: == Changes that could break older environments: - --- * Previous versions of Ant's copy task would throw a BuildException if the "name" of the resource to copy was null. Starting this version, the copy task instead silently skips such resources and no longer throws an exception. ant-dev list https://www.mail-archive.com/dev@ant.apache.org/msg46634.html * Reverted the signature change of various clone method implementation in Ant's data-types introduced with 1.10.2 as they broke subclasses of said data-types which tried to override clone. Fixed bugs: - --- * Fixed NullPointerException in ChainedMapper Bugzilla Report 62086 * Fixed NullPointerException when a mappedresource is used in pathconvert Bugzilla Report 62076 * Fixed an issue where a string, when used as a resource collection, within tokens, would be replaced by property values Bugzilla Report 62147 * Added a workaround for a bug in the jarsigner tool to which requires the -storepass command line argument when verifying signatures using -strict together with a PKCS12 keystore. Unlike when signing the jar it will not prompt for the keystore's password and read it from standard input. This means Ant will now pass the keystore's password on the command line when using , which poses a security risk you should be aware of. Bugzilla Report 62194 Other changes: - -- * Allow Saxon to be used for junitreport XSL transformation Github Pull Request #57 * when running on Java 11+ rmic will fail early if iiop or idl are requested. Java11 removes support for CORBA and the switches have been removed from the rmic tool. * A new junitlauncher task which support JUnit 5 test framework. Bugzilla Report 61796 Changes in 1.9.11 include: = Changes that could break older environments: - --- * Previous versions of Ant's copy task would throw a BuildException if the "name" of the resource to copy was null. Starting this version, the copy task instead silently skips such resources and no longer throws an exception. ant-dev list https://www.mail-archive.com/dev@ant.apache.org/msg46634.html Fixed bugs: - --- * Fixed NullPointerException when a mappedresource is used in pathconvert Bugzilla Report 62076 * Added a workaround for a bug in the jarsigner tool to which requires the -storepass command line argument when verifying signatures using -strict together with a PKCS12 keystore. Unlike when signing the jar it will not prompt for the keystore's password and read it from standard input. This means Ant will now pass the keystore's password on the command line when using , which poses a security risk you should be aware of. Bugzilla Report 62194 Other changes: - -- * when running on Java 11+ rmic will fail early if iiop or idl are requested. Java11 removes support for CORBA and the switches have been removed from the rmic tool. For complete information on Ant, including instructions on how to submit bug reports, patches, or suggestions for improvement, see the Apache Ant website: http://ant.a
Re: [VOTE] Release Ant 1.10.3 based on RC2
+1. Verified that the changes in the junitlauncher task documentation are present. Also ran some local projects with this new 1.10.3 tar.gz and all was fine. -Jaikiran On 24/03/18 6:18 PM, Stefan Bodewig wrote: Hi all I've created a new release candidate for 1.10.3 incorporating the doc fix for junitlauncher: git tag: ANT_1.10.3_RC2 on commit: 1b9cc239e tarballs: https://dist.apache.org/repos/dist/dev/ant/ revision: 25934 Maven artifacts: https://repository.apache.org/content/repositories/orgapacheant-1025/org/apache/ant/ This Vote will be open at least for 72 hours and close no earlier than 2018-03-27 13:00UTC. Cheers Stefan - 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
Re: junitlauncher doc fix (was Re: [VOTE] Release Ant 1.10.3 based on RC1)
On 24/03/18 1:03 PM, Stefan Bodewig wrote: On 2018-03-24, Jaikiran Pai wrote: I'm not sure if for the documentation fix (which I have pushed upstream) we need to redo a new RC release. If I understand your change correctly then the manual as would be released with 1.10.3 is plain wrong and will cause people who trust it to bang their heads on the wall if things don't work. Yes, that's right - the documentation on the classpath element was wrong and what it claimed, isn't supported in this release. (2) roll RC2 with your fix I'm leaning towards the second option. Sounds fine to me. Sorry, I should have thoroughly read and cleaned up that doc a while back, but couldn't get to it until today. -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: ant git commit: Add dependency description
JUnit 5 introduces a new set of APIs which separates out the launching aspects and the test identification and execution of those tests. As such, the launcher APIs is what the junitlauncher task uses/requires. Test engines on the other hand are pluggable and aren't necessary for the junitlauncher task itself to be functional. Of course, the absence of a test engine implies there won't be any tests that will get run. However, which test engine to use is up to the users to decide and the junitlauncher task itself doesn't need those libraries for itself. As for the ability to have the JUnit 5 libraries, including the platform launcher API jars, within the classpath element of the junitlauncher task - it's not straightforward to accomplish for reasons noted in[1]. The JUnit task has very complex logic (for valid reasons) to support this specific use case (since 1.7.0 of Ant). So at this point, that's not something that I wanted to attempt or support. One thing however, that I do plan to experiment and probably support in a subsequent release is the ability to have the test engine library jars (and _not_ the JUnit 5 platform launcher API jars) within the classpath element of the junitlauncher task. I had attempted this in the very first version of this task, but ran into certain classloader issues which I did not time to investigate, so decided to push it out for now. [1] http://ant.apache.org/faq.html#delegating-classloader -Jaikiran On 17/03/18 8:39 PM, Gintautas Grigelionis wrote: Thanks for correcting the omission. But, the task manual page states that junit.jar of JUnit 4 might still be necessary ... For junit-vintage engine: - junit-vintage-engine.jar - junit.jar (JUnit 4.x version) ... so perhaps it's worth a note anyway. I was wondering why junitlauncher task depended on all jars being present in Ant classpath with no possibility to set a separate classpath for the task? Gintas 2018-03-17 15:05 GMT+01:00 Jaikiran Pai : The change noted in this commit isn't actually needed i.e. the junitlauncher task doesn't require the junit.jar to be available as noted in the junitlauncher task's manual. I however forgot to include the JUnit 5 platform API dependencies in this Library Dependencies table, which I'll add now. -Jaikiran On 17/03/18 7:22 PM, gin...@apache.org wrote: Repository: ant Updated Branches: refs/heads/master 50b9be737 -> a312b6728 Add dependency description Project: http://git-wip-us.apache.org/repos/asf/ant/repo Commit: http://git-wip-us.apache.org/repos/asf/ant/commit/a312b672 Tree: http://git-wip-us.apache.org/repos/asf/ant/tree/a312b672 Diff: http://git-wip-us.apache.org/repos/asf/ant/diff/a312b672 Branch: refs/heads/master Commit: a312b6728acb7a8d1f8765899615205b3042cb7e Parents: 50b9be7 Author: Gintas Grigelionis Authored: Sat Mar 17 14:52:06 2018 +0100 Committer: Gintas Grigelionis Committed: Sat Mar 17 14:52:06 2018 +0100 -- manual/install.html | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/ant/blob/a312b672/man ual/install.html -- diff --git a/manual/install.html b/manual/install.html index 191f3da..cfe9266 100644 --- a/manual/install.html +++ b/manual/install.html @@ -787,7 +787,9 @@ these tasks available. Please refer to the Installing A junit.jar -junit task (may be in classpath passed to task rather than Ant's classpath) +junit task (may be in classpath passed to task rather than + Ant's classpath) and junitlauncher task (must be on + Ant's classpath) https://junit.org/"; target="_top">https://junit.org/ - 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
Re: [VOTE] Release Ant 1.9.11 based on RC1
+1 - Downloaded the apache-ant-1.9.11-bin.tar.gz - Set ANT_HOME to this version, built ant-ivy repo using this version -ALL OK - Built a couple of local projects using this version - ALL OK - A brief check of the manualshows no major issues. I committed a fix in the documentation related to the binary distribution's layout to upstream[1], but I don't thinkthat's a big enough change to warrant another RCfor this release. [1] https://github.com/apache/ant/commit/a3b065b967b87641dc0e5a154a44002395f656c8 -Jaikiran On 23/03/18 11:03 PM, Stefan Bodewig wrote: correction, the Maven artifacts are at https://repository.apache.org/content/repositories/orgapacheant-1022/org/apache/ant/ Sorry Stefan On 2018-03-23, Stefan Bodewig wrote: Hi all I've created a release candidate for 1.9.11: git tag: ANT_1_9_11_RC1 on commit: 6f58cfd tarballs: https://dist.apache.org/repos/dist/dev/ant/ revision: 25910 Maven artifacts: https://repository.apache.org/content/repositories/orgapacheant-1120/org/apache/ant/ This Vote will be open at least for 72 hours and close no earlier than 2018-03-26 17:30UTC. Cheers Stefan - 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 - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [VOTE] Release Ant 1.10.3 based on RC1
+1. Except for a documentation issue which I explain below, rest all looks fine. I'm not sure if for the documentation fix (which I have pushed upstream) we need to redo a new RC release. - Downloaded apache-ant-1.10.3-bin.tar.gz - set ANT_HOME to this version and built ant-ivy repo (ant clean jar) using this version - ALL OK (previous 1.10.2 was failing with a compilation error as noted in [1]) - Checked out lucene-solr repo[2] and ran "ant compile" - LOOKS FINE (no longer fails with NPE as reported in [3]. I didn't test the whole build process of that repo though) - Read through the junitlauncher manual. Verified its usage as documented against a local project which uses a combination of JUnit4 and JUnit5 tests. Ran the tests using this new task and verified the results and formatted results. - ALL OK except a documentation issue. The doc issue in the junitlauncher task documentation about nested classpath element has now been fixed upstream[4] a few minutes back. [1] https://www.mail-archive.com/dev@ant.apache.org/msg46747.html [2] https://github.com/apache/lucene-solr [3] https://bz.apache.org/bugzilla/show_bug.cgi?id=62086 [4] https://github.com/apache/ant/commit/12c975888a762f0f901391a1bf27703360d179d0 -Jaikiran On 24/03/18 1:07 AM, Stefan Bodewig wrote: Hi all I've created a release candidate for 1.10.3: git tag: ANT_1.10.3_RC1 on commit: d00658c tarballs: https://dist.apache.org/repos/dist/dev/ant/ revision: 25917 Maven artifacts: https://repository.apache.org/content/repositories/orgapacheant-1024/org/apache/ant/ This Vote will be open at least for 72 hours and close no earlier than 2018-03-26 19:30UTC. Cheers Stefan - 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
Re: junitlauncher dependency on JUnit4?
Hi Stefan, This looks like some odd merge or squashing issue when I pushed that task changes. I have fixed it. The task itself doesn't need any JUnit test engine specific dependencies like this one. I just pushed the commit upstream which should fix this. P.S: I haven't responded to some other mails due to limited internet connectivity this few days. I'll respond to them soon. -Jaikiran On 20/03/18 8:57 PM, Stefan Bodewig wrote: Hi I've just added a POM for ant-junitlauncher and it currently fails to build as org.apache.tools.ant.taskdefs.optional.junitlauncher.SingleTestClass has a dependency on org.junit.Test and I haven't declared any dependency on JUnit4 inside the POM (only transitively with scope test). The class has an @Test annotation inside of the main build tree, is this intentional? To me it looks as if the annotation and the import of org.junit.Test could be removed. Stefan - 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
