Re: JDK 13 enters Rampdown Phase One

2019-06-20 Thread Jaikiran Pai
Hi Rory,

No issues uncovered for this build against our Ant project on a Linux
system.

https://builds.apache.org/job/Ant%20Master%20(latest%20EA%20JDK)/jdk_axis=jdk13-ea,label_exp=ubuntu/16/


(Failures there are known failures).

-Jaikiran

On 16/06/19 11:10 AM, Rory O'Donnell wrote:
> Hi Stefan/Jaikiran,
>
> *JDK 13 Early Access build **25 is now available **at : -
> jdk.java.net/13/*
>
>  * Per the JDK 13 schedule [1], we are now in Rampdown Phase One.
>  o For more details , see Mark Reinhold's email to jdk-dev mailing
>    list [2]
>  o The overall feature set is frozen, no further JEPs will be
>    targeted to this release.
>  * Changes in this build 25 [4]
>
> *Request for feedback on JEP 353 integrated in b24
> *
>
> JEP 353: Reimplement the Legacy Socket API" has been integrated into
> jdk-13+24. It would be very useful if applications or libraries using
> java.net.Socket or java.net.ServerSocket APIs could test with this
> build and report any issues found. The JEP provides information on the
> system property that can be used to switch back to the old
> implementation and that may be useful to check for behavior
> differences between the old and new implementation. It would be very
> useful to get feedback via the OpenJDK net-dev mailing list, bugs via
> the usual channel.
>
> *Updates to Release Notes since last email*
>
>  * b25 - Support Kerberos cross-realm referrals (RFC 6806)(JDK-8215032
>    <https://bugs.openjdk.java.net/browse/JDK-8215032>)
>  * b25 - Add -XX:SoftMaxHeapSize flag(JDK-8222145
>    <https://bugs.openjdk.java.net/browse/JDK-8222145>)
>  * b24 - Reimplement the Legacy Socket API(JDK-8221481
>    <https://bugs.openjdk.java.net/browse/JDK-8221481>)
>  o see above request for feedback
>  * b24  - Deprecated rmic tool For Removal(JDK-8217412
>    <https://bugs.openjdk.java.net/browse/JDK-8217412>)
>  * b24 - New String constants for Canonical XML 1.1 URIs(JDK-8224767
>    <https://bugs.openjdk.java.net/browse/JDK-8224767>)
>  * b23 - Support for Unicode 12.1 (JDK-8221431
>    <https://bugs.openjdk.java.net/browse/JDK-8221431>)
>  * b21 - Upgrade CLDR to Version 35.1 (JDK-8221432
>    <https://bugs.openjdk.java.net/browse/JDK-8221432>)
>
> *OpenJDK 14 **Early Access build 1 **is now available **at : -
> jdk.java.net/14/*
>
>  * These early-access, open-source builds are provided under the GNU
>    General Public License, version 2, with the Classpath Exception
>    <http://openjdk.java.net/legal/gplv2+ce.html>.
>  * Changes in this build [5]
>
> **
>
> Rgds, Rory
>
> [1] http://openjdk.java.net/projects/jdk/13/#Schedule
> <http://openjdk.java.net/projects/jdk/12/#Schedule>
> [2] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-June/003060.html
> [3] http://jdk.java.net/13/release-notes
> [4] JDK 13 - Changes in b25 here
> <http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-13%2B24%22%3A%3A%22jdk-13%2B25%22-%22jdk-13%2B24%22%29=1000>
> [5] JDK 14 - Changes in b1 here
> <http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-14%2B0%22%3A%3A%22jdk-14%2B1%22-%22jdk-14%2B0%22%29=1000>
>

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



Re: Augmenting the ant wrapper script for OS packaging

2019-06-11 Thread Jaikiran Pai


On 11/06/19 9:54 PM, Stefan Bodewig wrote:
> I'm a bit torn but would prefer adding it to the default script so that
> running Ant would use the same wrapper no matter how you've installed
> it. I'm afraid we'd have to ask people "how have you installed Ant"
> otherwise.

+1.

Given that the startup script already does a bunch of things to locate a
Java installation and the fact that what you are proposing seems to be
pretty reasonable in terms of finding the "Snap JVM", I think it's good
to have it in the default script.

-Jaikiran


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



Re: [ant] branch master updated: Avoid connection refused errors by leaving some time between the gets, works locally lets see if it also works for jenkins

2019-05-27 Thread Jaikiran Pai
Hi Martijn,

You are right - these tests have been failing regularly with connection
refused issues on Jenkins. Your commit seems to have improved the
situation although, they still seem to fail once in a while like here
https://builds.apache.org/job/Ant-Build-Matrix-master-Windows/jdk=JDK%201.8.0_121%20(unlimited%20security)%2064-bit%20Windows%20only,label_exp=Windows/894/testReport/junit/src.tests.antunit.taskdefs/get-test_xml/testTemporaryRedirect/

-Jaikiran

On 26/05/19 12:35 PM, j...@apache.org wrote:
> Hi all
>
> Sorry the patch also contains another change, yesterday I updated the
> get-test.xml to also use https to the extend possible, and I did
> "break" the test case following a redirect from http to https. After
> fixing this I immediately put a workaround in place for the connection
> refused errors we often get in the get-test and gunzip-test.
>
> Br Martijn
>
>
>
> On 26-05-19 08:46, j...@apache.org wrote:
>> This is an automated email from the ASF dual-hosted git repository.
>>
>> jkf pushed a commit to branch master
>> in repository https://gitbox.apache.org/repos/asf/ant.git
>>
>>
>> The following commit(s) were added to refs/heads/master by this push:
>>   new 9b4393b  Avoid connection refused errors by leaving some
>> time between the gets, works locally lets see if it also works for
>> jenkins
>> 9b4393b is described below
>>
>> commit 9b4393b85ca7acebd7b228ea5ee79e4aa7e810a8
>> Author: jkf 
>> AuthorDate: Sun May 26 08:46:09 2019 +0200
>>
>>  Avoid connection refused errors by leaving some time between the
>> gets, works locally lets see if it also works for jenkins
>> ---
>>   src/tests/antunit/taskdefs/get-test.xml    | 12 +++-
>>   src/tests/antunit/taskdefs/gunzip-test.xml |  2 ++
>>   2 files changed, 13 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/tests/antunit/taskdefs/get-test.xml
>> b/src/tests/antunit/taskdefs/get-test.xml
>> index b6b5e11..2133321 100644
>> --- a/src/tests/antunit/taskdefs/get-test.xml
>> +++ b/src/tests/antunit/taskdefs/get-test.xml
>> @@ -20,12 +20,14 @@
>>     
>>       > value="https://ant.apache.org/webtest/gettest; />
>> +  > value="http://ant.apache.org/webtest/gettest/http-to-https.txt; />
>>       
>>   
>>     
>>       
>> +    
>>   
>>     
>>   
>> @@ -39,6 +41,7 @@
>>     
>>     
>> +  
>>     > dest="${output}/permanent.tmp"/>
>>   
>>     
>> @@ -52,6 +55,7 @@
>>   
>>     
>> +  
>>     
>>   
>>     
>> @@ -65,6 +69,7 @@
>>   
>>     
>> +  
>>     
>>   
>>     
>> @@ -78,6 +83,7 @@
>>   
>>     
>> +  
>>     
>>   
>>     
>> @@ -95,6 +101,7 @@
>>       
>> +  
>>     
>>     > dest="${output}/infinite.tmp"/>
>>   
>> @@ -102,6 +109,7 @@
>>       
>> +  
>>     
>>   https://ant.apache.org/index.html"/>
>>   https://ant.apache.org/faq.html"/>
>> @@ -111,6 +119,7 @@
>>   
>>       
>> +    
>>   
>>   
>>     
>> @@ -125,7 +134,8 @@
>>       
>> -    > dest="${output}/http-to-https-redirect.tmp"/>
>> +    
>> +    > dest="${output}/http-to-https-redirect.tmp"/>
>>   
>>   
>>     > resource="${output}/http-to-https-redirect.tmp" substring="hello
>> world"/>
>> diff --git a/src/tests/antunit/taskdefs/gunzip-test.xml
>> b/src/tests/antunit/taskdefs/gunzip-test.xml
>> index f8ec6d9..19ca0ce 100644
>> --- a/src/tests/antunit/taskdefs/gunzip-test.xml
>> +++ b/src/tests/antunit/taskdefs/gunzip-test.xml
>> @@ -39,6 +39,7 @@
>>     
>>       
>> +    
>>   
>>     > url="https://ant.apache.org/webtest/gunzip/greeting.txt.gz"/>
>>   
>> @@ -49,6 +50,7 @@
>>     
>>       
>> +    
>>   
>>     > url="https://ant.apache.org/webtest/gunzip/greeting.txt.gz"/>
>>   
>>
>
> -
> 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: Unintentional broken compatibility of Ant 1.10.6 with Java 8

2019-05-24 Thread Jaikiran Pai


On 24/05/19 9:56 AM, Stefan Bodewig wrote:
> On 2019-05-24, Jaikiran Pai wrote:
>
>> As you all might know, we released Ant 1.10.6 some days back. That
>> release was built using Java 11 but targeted to be usable with Java 8
>> (our minimum requirement runtime that we support). However, due to a bug
>> in our build and release process, we have broken the compatibility of
>> this version against Java 8.
> I remember we had a similar case years ago when Java 1.4 introduced
> StringBuffer.append(StringBuffer) and a release built on 1.4 would no
> longer work on 1.3. This is too bad. Can --release fix it only if Java8
> is installed (or at least its rt.jar) in additon to the JDK your
> building with?

From my experimentation so far, the --release fixes it (keeping aside
our Java9+ tasks) without asking for a Java 8 installation (with
JAVA_HOME pointing to a higher, for example Java 11 version). The
documentation[1] doesn't say much on how it does that, but I guess the
JDK ships with these public APIs for the (limited) supported --release
versions.

That in itself isn't a solution though because we need to tackle the
other main issue - if we do set --release option in our javac, as stated
in the documentation[1] of this attribute, this ends up using (only) the
public APIs available in Java 8 (the version we use for the --release
attribute). This effectively means that you will end up seeing compile
errors for the jmod and the link tasks (the new ones) even when using
JAVA_HOME pointing to Java 11.

So I'm in the process of restructuring the build.xml (and issue a PR for
review) to accommodate the following:

1. Mandate/force Java 9+ (preferably Java 11) for release managers and
optionally let other users specify it.

2. Split out the compilation process of the new Java 9+ tasks from the
current existing compilation target(s).

3. Use --release = 8 for all "regular" (the targets not meant to compile
Java 9+ code) javac tasks in addition to --source and --target = 1.8. If
users build Ant with Java 8, the --release will be ignored (that's a
feature of our javac task) and if they build with Java 9+, the --source
--target will be ignored (that's a feature of the JDK's javac). So using
all 3 of these attributes should be fine without the need for additional
conditionals.

4. Compile Java 9+ code (the new tasks) with --source, --target = 1.8
and _without_ the --release attribute. This will effectively let it
compile fine and use the new Java 9+ Java APIs. Plus it will allow these
tasks to be functional in Java 9+ environments.

5. Mandate/force (through the build.xml) the release manager to run our
existing tests through *both* the Java runtime that's being used to
build the project and also against Java 8 (the minimal version we
support). This is one of things we got wrong in our release/build
process and missed catching this issue. What we have been doing is
building and running the tests in the same version. So although we have
our Jenkins CI running against Java 8, 9, 11 - all of them compile the
code and then run these tests on the same version from start to the end.
With this new proposed mechanism, we should be able to catch issues like
this, in future. Of course, I don't plan to mandate this on every one,
so this will be a separate target which is responsible for running these
tests against multiple Java version and will only be mandated for
release managers. Others (including our CI jobs) will have a choice to
run them.

6. This step is really optional and something that I haven't fully
thought through. I was thinking maybe while we are at it, make these new
Java 9+ task resources (classes and any other related artifacts), into a
multi-release jar. But I don't see this as a necessity to sort out our
current issue.

7. Update our CI jobs to use Java 11 as the JAVA_HOME and then run the
testsuite using Java 8, 9, 10 and 11 (the new build.xml target that I
propose in #5 should simplify this process).

In theory, I guess what I have outlined in above steps should get us
past this issue. I will know more when I get something working.

All this said, I haven't yet had the time to look into the archives of
OpenJDK mailing lists to see if this was a expected incompatibility
change in that class or whether this needs to be discussed. I'll take
that up later though.


>> This mail is just an advance notice to users who might have been
>> planning to upgrade their setups to this released version, to wait for a
>> newer release,
> Sounds as if we should also put that as "news" on the website, on the
> home page and into the FAQ (known problems).
Yes, that sounds right. I can take this up later tonight if no one else
gets there before me.

[1]
https://docs.oracle.com/en/java/javase/11/tools/javac.html#GUID-AEEC9F07-CB49-4E96-8BC7-BCC2C7F725C9

-Jaikiran



Unintentional broken compatibility of Ant 1.10.6 with Java 8

2019-05-23 Thread Jaikiran Pai
As you all might know, we released Ant 1.10.6 some days back. That
release was built using Java 11 but targeted to be usable with Java 8
(our minimum requirement runtime that we support). However, due to a bug
in our build and release process, we have broken the compatibility of
this version against Java 8. One such issue has been reported here
https://bz.apache.org/bugzilla/show_bug.cgi?id=63457 and a fix (and a
prevention to hopefully not run into these issues again) is being worked
upon. This obviously will involve a new release of Ant 1.10.x.

This mail is just an advance notice to users who might have been
planning to upgrade their setups to this released version, to wait for a
newer release, if you plan to use this version against Java 8. In the
meantime, you can still try out the 1.10.6 release and report any other
issues that you might run into.

-Jaikiran




signature.asc
Description: OpenPGP digital signature


Re: Updating bugzilla with recent releases of Ant

2019-05-10 Thread Jaikiran Pai
Thank you Stefan.

-Jaikiran

On 10/05/19 6:40 PM, Stefan Bodewig wrote:
> On 2019-05-10, Jaikiran Pai wrote:
>
>> Can one of us, who has admin rights in bugzilla, please do the necessary?
> 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



Updating bugzilla with recent releases of Ant

2019-05-10 Thread Jaikiran Pai
One of the steps that I couldn't complete during the 1.9.14 and 1.10.6
release was to update our Bugzilla to mark these versions as released
and create new versions for bug tracking.

Can one of us, who has admin rights in bugzilla, please do the necessary?

-Jaikiran


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



Re: JDK 13 - Early Access build 20 is available

2019-05-10 Thread Jaikiran Pai
Thank you Muneer.

-Jaikiran

On 10/05/19 4:33 PM, abdul.kolarku...@oracle.com wrote:
> Hi Jai,
> 
> Thanks for the feedback.
> 
> The bug you filed is a duplicate of
> https://bugs.openjdk.java.net/browse/JDK-8223627 which is already
> resolved and we can expect fix in the next build.
> 
> So I closed it as a duplicate of the same.
> 
> -Muneer
> 
> 
> On 10/05/19 4:19 PM, Jaikiran Pai wrote:
>> Hello Rory,
>>
>> Though a quick run of our testsuite against this build 20 of JDK 13
>> passed without any regressions, I did notice an issue with this build.
>> I've created https://bugs.openjdk.java.net/browse/JDK-8223695 to track
>> it. I hope it's OK that I directly created it in the JIRA instead of
>> discussing in the OpenJDK mailing list first.
>>
>> -Jaikiran
>>
>> On 10/05/19 1:18 PM, Rory O'Donnell wrote:
>>> Hi Stefan/Jaikiran,
>>>
>>>
>>>   *OpenJDK builds *- JDK 13 - Early Access build 20 is available at
>>>   http://jdk.java.net/13/
>>>
>>>   * These early-access , open-source builds are provided under the
>>>   o GNU General Public License, version 2, with the Classpath
>>>     Exception <http://openjdk.java.net/legal/gplv2+ce.html>.
>>>   * Changes in this build
>>>   
>>> <http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-13%2B19%22%3A%3A%22jdk-13%2B20%22-%22jdk-13%2B19%22%29=1000>
>>>
>>>   * Release notes [1]
>>>
>>>
>>>   *Significant changes since the last availability email*
>>>
>>>   * build 20
>>>   o Removal of T-Systems Deutsche Telekom Root CA 2 certificate
>>>     (JDK-8222137)
>>>   o Add new FileSystems.newFileSystem methods (JDK-8218875)
>>>   o Enhance auto vectorization for x86 (JDK-8222074)
>>>   o Remove CollectorPolicy and its subclasses (JDK-8198505)
>>>   o Drop support for pre JDK 1.4 SocketImpl implementations
>>>     (JDK-8216978)
>>>   * build 19
>>>   o add support for generating method handles from a variable symbol
>>>     (JDK-8222744)
>>>   o mark new VM option AllowRedefinitionToAddOrDeleteMethods as
>>>     deprecated (JDK-8222934)
>>>   * build 18
>>>   o Improve String::equals warmup characteristics (JDK-8215017)
>>>   o [Containers] Improve systemd slice memory limit support
>>>     (JDK-8217338)
>>>
>>>
>>>     Bug fixes for issues reported by Open Source Projects
>>>
>>>   * build 20
>>>   o assert(Compile::current()->live_nodes() <
>>>     Compile::current()->max_node_limit()) failed: Live Node limit
>>>     exceeded limit (JDK-8219520)
>>>   o C2: MemNode::can_see_stored_value() ignores casts which carry
>>>     control dependency (JDK-8219902)
>>>   o New fix of the deadlock in sun.security.ssl.SSLSocketImpl
>>>     (JDK-8219991)
>>>
>>>
>>>   JEP updates since last email
>>>
>>>   * JEP 350: Dynamic CDS Archives <http://openjdk.java.net/jeps/350>
>>>     istargeted for JDK 13.
>>>   * JEP 351: ZGC: Uncommit Unused Memory
>>>     <http://openjdk.java.net/jeps/351> istargeted for JDK 13
>>>   * JEP 353: Reimplement the Legacy Socket API
>>>     <http://openjdk.java.net/jeps/353> moved to Candidate
>>>   * JEP 354: Switch Expressions <http://openjdk.java.net/jeps/354> moved
>>>     to Candidate.
>>>
>>>
>>>   OpenJDK Committers’ Workshop, 1–2 August 2019 [2]
>>>
>>> Rgds,Rory
>>>
>>> [1] http://jdk.java.net/13/release-notes
>>> [2]
>>> https://mail.openjdk.java.net/pipermail/announce/2019-April/000269.html
>>>
> 

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



Re: JDK 13 - Early Access build 20 is available

2019-05-10 Thread Jaikiran Pai
Hello Rory,

Though a quick run of our testsuite against this build 20 of JDK 13
passed without any regressions, I did notice an issue with this build.
I've created https://bugs.openjdk.java.net/browse/JDK-8223695 to track
it. I hope it's OK that I directly created it in the JIRA instead of
discussing in the OpenJDK mailing list first.

-Jaikiran

On 10/05/19 1:18 PM, Rory O'Donnell wrote:
>
> Hi Stefan/Jaikiran,
>
>
>  *OpenJDK builds *- JDK 13 - Early Access build 20 is available at
>  http://jdk.java.net/13/
>
>  * These early-access , open-source builds are provided under the
>  o GNU General Public License, version 2, with the Classpath
>    Exception <http://openjdk.java.net/legal/gplv2+ce.html>.
>  * Changes in this build
>   
> <http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-13%2B19%22%3A%3A%22jdk-13%2B20%22-%22jdk-13%2B19%22%29=1000>
>  * Release notes [1]
>
>
>  *Significant changes since the last availability email*
>
>  * build 20
>  o Removal of T-Systems Deutsche Telekom Root CA 2 certificate
>    (JDK-8222137)
>  o Add new FileSystems.newFileSystem methods (JDK-8218875)
>  o Enhance auto vectorization for x86 (JDK-8222074)
>  o Remove CollectorPolicy and its subclasses (JDK-8198505)
>  o Drop support for pre JDK 1.4 SocketImpl implementations
>    (JDK-8216978)
>  * build 19
>  o add support for generating method handles from a variable symbol
>    (JDK-8222744)
>  o mark new VM option AllowRedefinitionToAddOrDeleteMethods as
>    deprecated (JDK-8222934)
>  * build 18
>  o Improve String::equals warmup characteristics (JDK-8215017)
>  o [Containers] Improve systemd slice memory limit support
>    (JDK-8217338)
>
>
>    Bug fixes for issues reported by Open Source Projects
>
>  * build 20
>  o assert(Compile::current()->live_nodes() <
>    Compile::current()->max_node_limit()) failed: Live Node limit
>    exceeded limit (JDK-8219520)
>  o C2: MemNode::can_see_stored_value() ignores casts which carry
>    control dependency (JDK-8219902)
>  o New fix of the deadlock in sun.security.ssl.SSLSocketImpl
>    (JDK-8219991)
>
>
>  JEP updates since last email
>
>  * JEP 350: Dynamic CDS Archives <http://openjdk.java.net/jeps/350> 
>    istargeted for JDK 13.
>  * JEP 351: ZGC: Uncommit Unused Memory
>    <http://openjdk.java.net/jeps/351> istargeted for JDK 13
>  * JEP 353: Reimplement the Legacy Socket API
>    <http://openjdk.java.net/jeps/353> moved to Candidate
>  * JEP 354: Switch Expressions <http://openjdk.java.net/jeps/354> moved
>    to Candidate.
>
>
>  OpenJDK Committers’ Workshop, 1–2 August 2019 [2]
>
> Rgds,Rory
>
> [1] http://jdk.java.net/13/release-notes
> [2]
> https://mail.openjdk.java.net/pipermail/announce/2019-April/000269.html
>

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



[ANNOUNCE] Apache Ant 1.10.6 released

2019-05-08 Thread Jaikiran Pai
can be packaged as multi-release jars,
   AntClassLoader now recognizes such multi-release jar files while
   loading resources at runtime in Java 9+ runtime environments.
   Bugzilla Report 62952

 * Added jmod and link tasks, to support jmod and jlink tools of JDK 9+.
   Github Pull Request #80

 * Jsch library dependency has now been upgraded to 0.1.55. Jsch is
   the library behind the sshexec and scp Ant tasks.
   Github Pull Request #84

 * The "http" condition, now has a "readTimeout" attribute which can be
   used to control the amount of time to wait for the read to complete.
   Bugzilla Report 63193

 * ftp task manual has been updated to mention that the remote listing of
   files honours the followsymlinks attribute.
   Bugzilla Report 63226

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, on behalf of the Apache Ant community








signature.asc
Description: OpenPGP digital signature


[RESULT] [VOTE] Release Ant 1.10.6 based on RC2

2019-05-06 Thread Jaikiran Pai
With +1s from:

Stefan

Maarten

Jaikiran

and no vetos, this vote now passes.

I will proceed with the rest of the release formalities.

Thank you for voting.

-Jaikiran

On 07/05/19 9:45 AM, Stefan Bodewig wrote:
> On 2019-05-02, Jaikiran Pai wrote:
>
>> I've created a release candidate RC2 for 1.10.6. This release contains
>> bug fixes as well as enhancements.
> +1
>
> 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.10.6 based on RC2

2019-05-06 Thread Jaikiran Pai
+1

- Downloaded the .tar.gz binary.

- Used this version to build some of our internal projects

- Checked the NOTICE file

- Checked some random task manuals

All looks fine.

-Jaikiran

On 02/05/19 7:46 PM, Jaikiran Pai wrote:
> Hello all,
>
> I've created a release candidate RC2 for 1.10.6. This release contains
> bug fixes as well as enhancements.
>
> The release was generated using JDK 11 version (to include JDK9+
> features/tasks). The minimal required version of Java runtime, to use
> this Ant release, still remains Java 8.
>
> Release notes:
>     https://dist.apache.org/repos/dist/dev/ant/RELEASE-NOTES-1.10.6.html
>
> git tag:
>     ANT_1.10.6_RC2 on commit e4a56ec5bd155fccf176ea37a778c486ac5cb92c
>
> tarballs:
>     https://dist.apache.org/repos/dist/dev/ant/
>     revision 33883
>
> Maven artifacts:
>   
> https://repository.apache.org/content/repositories/orgapacheant-1038/org/apache/ant/
>
> This Vote will be open at least for 72 hours and close no earlier than
> 5th May 2019 14:30 UTC.
>
> -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] Release Ant 1.10.6 based on RC2

2019-05-02 Thread Jaikiran Pai
Hello all,

I've created a release candidate RC2 for 1.10.6. This release contains
bug fixes as well as enhancements.

The release was generated using JDK 11 version (to include JDK9+
features/tasks). The minimal required version of Java runtime, to use
this Ant release, still remains Java 8.

Release notes:
    https://dist.apache.org/repos/dist/dev/ant/RELEASE-NOTES-1.10.6.html

git tag:
    ANT_1.10.6_RC2 on commit e4a56ec5bd155fccf176ea37a778c486ac5cb92c

tarballs:
    https://dist.apache.org/repos/dist/dev/ant/
    revision 33883

Maven artifacts:
  
https://repository.apache.org/content/repositories/orgapacheant-1038/org/apache/ant/

This Vote will be open at least for 72 hours and close no earlier than
5th May 2019 14:30 UTC.

-Jaikiran


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



Re: JDK 13 - Early Access build 17 is available

2019-05-02 Thread Jaikiran Pai
Hello Rory,

I just gave JDK 13 (build 18) a try with our master branch of Ant on a
Linux system and all seems fine[1] (no unexpected failures)

[1]
https://builds.apache.org/job/Ant%20Master%20(latest%20EA%20JDK)/jdk_axis=jdk13-ea,label_exp=ubuntu/13/

-Jaikiran

On 19/04/19 5:34 PM, Rory O'Donnell wrote:
>
> *Hi Stefan/Jaikiran, *
>
> *OpenJDK builds *- JDK 13 - Early Access build 17 is available at
> http://jdk.java.net/13/
>
>  * These early-access , open-source builds are provided under the
>  o GNU General Public License, version 2, with the Classpath
>    Exception <http://openjdk.java.net/legal/gplv2+ce.html>.
>  * Changes in this build
>   
> <http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-13%2B16%22%3A%3A%22jdk-13%2B17%22-%22jdk-13%2B16%22%29=1000>
>  * Release notes [1]
>
> *Significant changes since the last availability email*
>
>  * build 16 - Update the default enabled cipher suites preference
>    (JDK-8163326 <https://bugs.openjdk.java.net/browse/JDK-8163326>)
>  * build 16 - Add new keytool -showinfo -tls command for displaying TLS
>    configuration information (JDK-8219861
>    <https://bugs.openjdk.java.net/browse/JDK-8219861>)
>  * build 15  -*New Japanese Era Name **(JDK-8205432
>    <https://bugs.openjdk.java.net/browse/JDK-8205432>)*
>  * build 15  - Accessing REIWA era in java.time.chrono.JapaneseEra
>    (JDK-8174268 <https://bugs.openjdk.java.net/browse/JDK-8174268>)
>  * build 15  - Duplicated RSA services are no longer supported by
>    SunJSSE provider (JDK-8220016
>    <https://bugs.openjdk.java.net/browse/JDK-8220016>)
>  * build 15  - Use server cipher suites preference by default
>    (JDK-8168261 <https://bugs.openjdk.java.net/browse/JDK-8168261>)
>  * build 15  - The Swing Motif Look and Feel is deprecated and
>    unsupported on macOS (JDK-8177960
>    <https://bugs.openjdk.java.net/browse/JDK-8177960>)
>  * build 15  - Remove support for javadoc "frames" mode (JDK-8215599
>    <https://bugs.openjdk.java.net/browse/JDK-8215599>)
>
> Bug fix reported by Open Source Projects  :
>
>  * build 15  - Unable to read certain PKCS12 keystores from
>    SequenceInputStream (JDK-8157404)
>    <https://bugs.openjdk.java.net/browse/JDK-8157404>
>
> *April 2019 CPU Released*
>
>  * As part of the Apr 2019 Critical Patch Update we released OpenJDK
>    12.0.1  under the GNU General Public License, version 2, with the
>    Classpath Exception <http://openjdk.java.net/legal/gplv2+ce.html>. [2]
>  * One change previously announced in the Java Cryptographic Roadmap [3]
>
> *Request for feedback *-  switch expressions in JDK 12  , feedback via
> amber-dev list [4]
>
> Rgds,Rory
>
> [1] http://jdk.java.net/13/release-notes
> [2] http://jdk.java.net/12
> [3] https://java.com/en/jre-jdk-cryptoroadmap.html
> [4]
> https://mail.openjdk.java.net/pipermail/jdk-dev/2019-April/002770.html
>

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



Re: JDK 13 - Early Access build 14 is available

2019-04-09 Thread Jaikiran Pai
Hi Rory,

I forgot to reply to this.

Our tests against JDK 12 GA and JDK 13 EA (build 15), on Linux system,
haven't shown any regressions. Tests against these versions [1][2] have
passed without any new failures (the ones you see in those jobs are
known failures and aren't related to the JDK version).

[1]
https://builds.apache.org/job/Ant%20Master%20(latest%20EA%20JDK)/jdk_axis=jdk12-ea,label_exp=ubuntu/11/

[2]
https://builds.apache.org/job/Ant%20Master%20(latest%20EA%20JDK)/jdk_axis=jdk13-ea,label_exp=ubuntu/11/

-Jaikiran

On 29/03/19 4:30 PM, Rory O'Donnell wrote:
> Hi Stefan/Jaikiran,
>
> *OpenJDK builds *- JDK 13 - Early Access build 14 is available at
> http://jdk.java.net/13/
>
>  * These early-access, open-source builds are provided under the GNU
>    General Public License, version 2, with the Classpath Exception
>    <http://openjdk.java.net/legal/gplv2+ce.html>.
>  * Changes in this build
>   
> <http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-13%2B13%22%3A%3A%22jdk-13%2B14%22-%22jdk-13%2B13%22%29=1000>
>  * Release notes [1]
>  * JDK 13 Schedule proposal accepted [2]
>  o 2019/06/13 Rampdown Phase One
>  o 2019/07/18 Rampdown Phase Two
>  o 2019/08/08 Initial Release Candidate
>  o 2019/08/22 Final Release Candidate
>  o 2019/09/17 General Availability
>
> *jpackage EA *
>
>  * This is an early access build of JEP 343: Packaging Tool
>    <https://openjdk.java.net/jeps/343>, aimed at testing a prototype
>    implementation of jpackage, which is a new tool for packaging
>    self-contained Java applications along with a Java Runtime
> Environment.
>  * Build 30 is now available http://jdk.java.net/jpackage/
>  * Please send feedback via e-mail to core-libs-...@openjdk.java.net
>    <mailto:core-libs-...@openjdk.java.net>
>
> *Quality Outreach report for **March 2019*
>
>  * The report for March 2019 is available here
>   
> <https://wiki.openjdk.java.net/display/quality/Quality+Outreach+report+March+2019>
>  * Thanks to all those contributed !
>
> *Recent Blog:* A new (Japanese) era for Java!
> <https://blogs.oracle.com/java-platform-group/a-new-japanese-era-for-java>
>
> Rgds,Rory
>
> [1] http://jdk.java.net/13/release-notes
> [2]
> https://mail.openjdk.java.net/pipermail/jdk-dev/2019-March/002736.html
>

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



Need inputs before starting a new RC for 1.10.6

2019-03-28 Thread Jaikiran Pai
After releasing the (now aborted) RC1 of 1.10.6 last week, I went back
to see how I managed to mess up that RC. While looking into that, I
uncovered an unrelated issue which I think now needs attention and
decision before I start a new RC release for 1.10.6.

As far as I understand the pom files that we maintain and publish to
Maven central are basic minimal. However, a bunch of relatively recent
commits have introduced certain changes to those poms. I have gone
through the mail discussion/commit logs to understand why this was done
and what goal it was trying to achieve and how it was trying to achieve
that. Reading that discussion, I haven't understood these changes and
nor do I understand them now after reviewing them again (there's more
than one commit).

However, the commit of note (or at least the issue I spotted was) is
this[1]. Specifically this content[2]. I don't understand why it's coded
to fetch a specific version of Ant. Is that version supposed to be
updated every time a newer release is done? What's the point of getting
a released version of Ant when the whole "latest" code of Ant is
available and built locally and can be used by these poms for whatever
tests need to be run against the Ant distribution?

Furthermore, when these poms are now released, the released 1.10.6
version (for example) will now end up having this (artificial)
dependency on 1.10.5 Ant zip distribution and that's a public facing
pom. Is that the right thing?

Any thoughts on how I should proceed? This isn't an isolated single
commit in the poms so I don't really know what impact it might have just
undoing this change (if that's the way to go).

For now, I won't be initiating a RC for 1.10.6 till we come to a
decision around these poms and this one in particular.

[1]
https://github.com/apache/ant/commit/f871e80a6a9f6165137d24b72e209a73283494e8#diff-da69e4ebd862444e205e118aa2aed802

[2]
https://github.com/apache/ant/commit/f871e80a6a9f6165137d24b72e209a73283494e8#diff-c4ff64043583b0162e0b77f91c2e8a1eR112

-Jaikiran



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



[CANCELLED] Release Ant 1.10.6 based on RC1

2019-03-20 Thread Jaikiran Pai
Voting for this RC1 is now cancelled due to the issues that Stefan
found. I'll re-initiate a new RC for voting process soon.

-Jaikiran

On 21/03/19 1:23 AM, Stefan Bodewig wrote:
> On 2019-03-19, Jaikiran Pai wrote:
>
>> git tag:
>>     ANT_1.10.6_RC1 on commit c3b75a72a78fd4cc1e1bd4bc345e5744872d44ef
> I think you've tagged the wrong commit (HEAD of master at that time
> rather than the detached head. The Source tarball doesn't match the tag
> and the tag still contains an .alpha version.
>
> If you can still find the head you've for creating the release, please
> delete the tag and move it over. Without that I'm unable to vote with a
> +1.
>
> Also I've found more test files without a license header - I really
> should have vetted releases I've cut myself more thoroughly.
>
> 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.10.6 based on RC1

2019-03-20 Thread Jaikiran Pai
Hi Stefan,

On 21/03/19 1:23 AM, Stefan Bodewig wrote:
> On 2019-03-19, Jaikiran Pai wrote:
>
>> git tag:
>>     ANT_1.10.6_RC1 on commit c3b75a72a78fd4cc1e1bd4bc345e5744872d44ef
> I think you've tagged the wrong commit (HEAD of master at that time
> rather than the detached head. The Source tarball doesn't match the tag
> and the tag still contains an .alpha version.

Thank you for catching that. I don't know how I ended up doing that. I
will cancel this vote and redo the release afresh from latest master branch.


> If you can still find the head you've for creating the release, please
> delete the tag and move it over. Without that I'm unable to vote with a
> +1.
>
> Also I've found more test files without a license header - I really
> should have vetted releases I've cut myself more thoroughly.

Are you finding this through some tool or doing manual checks in files?
I can include this as part of the release instructions and follow them
if this has some specific steps.


-Jaikiran


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



[VOTE] Release Ant 1.10.6 based on RC1

2019-03-19 Thread Jaikiran Pai
Hello all,

I've created a release candidate for 1.10.6. This release contains bug
fixes as well as enhancements.

The release was generated using JDK 11 version (to include JDK9+
features/tasks). The minimal required version of Java runtime, to use
this Ant release, still remains Java 8.

Release notes:
    https://dist.apache.org/repos/dist/dev/ant/RELEASE-NOTES-1.10.6.html

git tag:
    ANT_1.10.6_RC1 on commit c3b75a72a78fd4cc1e1bd4bc345e5744872d44ef

tarballs:
    https://dist.apache.org/repos/dist/dev/ant/
    revision 33068

Maven artifacts:
   
https://repository.apache.org/content/repositories/orgapacheant-1037/org/apache/ant/

This Vote will be open at least for 72 hours and close no earlier than
22nd March 2019 10:00 UTC.

-Jaikiran



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



[ANNOUNCE] Apache Ant 1.9.14 released

2019-03-17 Thread Jaikiran Pai
The Apache Ant Team is pleased to announce the release of Apache Ant 1.9.14.

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.5 unless you are required to use
versions of Java prior to Java8 during the build process.

This, Ant 1.9.14, release mainly consists of bug fixes and some
enhancements in the "signjar" and "verifyjar" tasks.

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.19.14 include:
==

Changes that could break older environments:
---

 * ClearCase#runS has been augmented by a two arg-version and the
   one-arg version will no longer be called. This may affect
   subclasses that have overridden runS.

Fixed bugs:
---

 * fetch.xml must retrieve runtime rather than compile dependencies for
   mail task.
   Bugzilla Report 62621

 * augment task now throws a BuildException (as noted in its manual)
   instead of a IllegalStateException in the absence of the "id" attribute.
   Bugzilla Report 62655

 * org.apache.tools.zip.ZipOutputStream would sometimes potentially use
   an incorrect compression level for a zip entry. This is now fixed.
   Bugzilla Report 62686

 * cccheckout would ignore an error of the "ls checkout" command even
   if failOnError was set to false.
   Bugzilla Report 63071

Other changes:
--
 * generatekey task now supports SubjectAlternativeName during key
   generation.

 * the modified> selector has a new built-in algorithm 'lastmodified'
   which computes a value based upon the lastmodified time of the file.

 * signjar and verifyjar now support the -providerName, -providerClass
   and -providerArg command line options of keytool via new attributes.
   Bugzilla Report 65234

 * signjar and verifyjar now supported nested arg> elements for
   command line arguments that are not supported explicitly by the
   tasks via attributes.

 * added several attributes to javadoc> that support modules.
   Bugzilla Report 62424

 * Jsch library dependency has now been upgraded to 0.1.55. Jsch is
   the library behind the sshexec and scp Ant tasks.
   Github Pull Request #84

 * ftp task manual has been updated to mention that the remote listing of
   files honours the followsymlinks attribute.
   Bugzilla Report 63226

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.apache.org/

- Jaikiran, on behalf of the Apache Ant community




signature.asc
Description: OpenPGP digital signature


[RESULT] Release Ant 1.9.14 based on RC1

2019-03-17 Thread Jaikiran Pai
Hi all,

With +1s from Maarten, Stefan and me (implicit) and no other votes, this
vote has passed.

I'll start the rest of the release process. Thank you for voting.

-Jaikiran

On 12/03/19 3:32 PM, Jaikiran Pai wrote:
> Hello all,
>
> I've created a new release candidate for 1.9.14. This release contains
> bug fixes as well as some enhancements.
>
> Release notes:
>        
>  https://dist.apache.org/repos/dist/dev/ant/RELEASE-NOTES-1.9.14.html
> git tag: ANT_1914_RC1
>  on commit: 8ec8ecf4eb94b238b09161055e75508155040180
> tarballs: https://dist.apache.org/repos/dist/dev/ant/
>  revision: 32887
> Maven artifacts:
> 
> https://repository.apache.org/content/repositories/orgapacheant-1036/org/apache/ant/
>
> This Vote will be open at least for 72 hours and close no earlier than
> 15th March 2019 10:00UTC.
>
> -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] Release Ant 1.9.14 based on RC1

2019-03-15 Thread Jaikiran Pai


On 14/03/19 11:31 AM, Stefan Bodewig wrote:
>
> I noticed two problems.
>
> * the NOTICE still hasn't been updated for 2019 - fixed in both branches
>
> * one file lacked the ASF required license header, and has lacked it for
>   more than a year - fixed in both branches
>
> Neither is a reason to block the release for me, in particular since the
> second thing has been part of past releases already and only affects a
> test case. Obviously I've not been strict enough with releases I've cut
> myself, sorry.

Thanks Stefan. I'll add a note about the NOTICE file header check in our
release instructions, so that we remember to check such files during the
release process.

-Jaikiran


-
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.14 based on RC1

2019-03-15 Thread Jaikiran Pai
+1

- Downloaded the .tar.gz binary

- Installed the new 1.9.14 release.

- Checked some manuals.

- Used this version to build some internal projects.

All went fine.

-Jaikiran

On 12/03/19 3:32 PM, Jaikiran Pai wrote:
> Hello all,
>
> I've created a new release candidate for 1.9.14. This release contains
> bug fixes as well as some enhancements.
>
> Release notes:
>        
>  https://dist.apache.org/repos/dist/dev/ant/RELEASE-NOTES-1.9.14.html
> git tag: ANT_1914_RC1
>  on commit: 8ec8ecf4eb94b238b09161055e75508155040180
> tarballs: https://dist.apache.org/repos/dist/dev/ant/
>  revision: 32887
> Maven artifacts:
> 
> https://repository.apache.org/content/repositories/orgapacheant-1036/org/apache/ant/
>
> This Vote will be open at least for 72 hours and close no earlier than
> 15th March 2019 10:00UTC.
>
> -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] Release Ant 1.9.14 based on RC1

2019-03-12 Thread Jaikiran Pai
Hello all,

I've created a new release candidate for 1.9.14. This release contains
bug fixes as well as some enhancements.

Release notes:
       
 https://dist.apache.org/repos/dist/dev/ant/RELEASE-NOTES-1.9.14.html
git tag: ANT_1914_RC1
 on commit: 8ec8ecf4eb94b238b09161055e75508155040180
tarballs: https://dist.apache.org/repos/dist/dev/ant/
 revision: 32887
Maven artifacts:

https://repository.apache.org/content/repositories/orgapacheant-1036/org/apache/ant/

This Vote will be open at least for 72 hours and close no earlier than
15th March 2019 10:00UTC.

-Jaikiran




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



Re: [ant] branch master updated: Incorrect HTML

2019-03-06 Thread Jaikiran Pai
Hi Eugène,

I have updated that manual and also marked this bugzilla as resolved.
Thanks for bringing this up.

-Jaikiran


On 06/03/19 12:50 PM, Eugène Adell wrote:
> Hello Jaikiran,
> 
> if you are changing the doc, there's one bug that I opened a couple of
> days ago ( https://bz.apache.org/bugzilla/show_bug.cgi?id=63226 ) and
> which is trivial. Maybe could you have a look ?
> 
> best regards
> E.A.
> 
> Le mer. 6 mars 2019 à 07:51,  a écrit :
>>
>> This is an automated email from the ASF dual-hosted git repository.
>>
>> jaikiran pushed a commit to branch master
>> in repository https://gitbox.apache.org/repos/asf/ant.git
>>
>>
>> The following commit(s) were added to refs/heads/master by this push:
>>  new 9e1bd14  Incorrect HTML
>> 9e1bd14 is described below
>>
>> commit 9e1bd1445d4269320e861ed05845e48e57f6f762
>> Author: twogee 
>> AuthorDate: Fri Mar 1 22:34:05 2019 +0100
>>
>> Incorrect HTML
>> ---
>>  manual/Tasks/conditions.html   |  3 +--
>>  manual/Tasks/ejb.html  |  1 -
>>  manual/Tasks/javadoc.html  | 14 +++---
>>  manual/Tasks/scriptdef.html|  2 +-
>>  manual/Tasks/serverdeploy.html |  6 +++---
>>  manual/Tasks/sshsession.html   |  1 -
>>  manual/Tasks/subant.html   |  2 +-
>>  manual/Tasks/wljspc.html   |  2 +-
>>  manual/cover.html  |  2 +-
>>  manual/properties.html |  2 +-
>>  manual/targets.html|  4 ++--
>>  manual/tutorial-tasks-filesets-properties.html |  9 +++--
>>  src/tutorial/tasks-filesets-properties/final/find.html |  6 +++---
>>  13 files changed, 24 insertions(+), 30 deletions(-)
>>
>> diff --git a/manual/Tasks/conditions.html b/manual/Tasks/conditions.html
>> index c494a30..f995e8e 100644
>> --- a/manual/Tasks/conditions.html
>> +++ b/manual/Tasks/conditions.html
>> @@ -217,11 +217,10 @@ URL. By default, HTTP responses errors of 400 or 
>> greater are viewed as invalid.<
>>
>>
>>  readTimeout
>> -Read timeout, in milli second, that will be used while reading from 
>> the target URL.
>> +Read timeout, in milliseconds, that will be used while reading from 
>> the target URL.
>>Accepts any value  0. Value of 0 implies wait indefinitely. Value 
>>  0 will be silently
>>ignored.
>>since Ant 1.10.6
>> -
>>  No; defaults to 0
>>
>>  
>> diff --git a/manual/Tasks/ejb.html b/manual/Tasks/ejb.html
>> index 9fa87b5..f5bf654 100644
>> --- a/manual/Tasks/ejb.html
>> +++ b/manual/Tasks/ejb.html
>> @@ -1523,7 +1523,6 @@ example, suffix). Refer to the appropriate 
>> documentation for more det
>>this if you prefer to run GenIC at deployment time.
>>No; defaults to false
>>  
>> -
>>
>>  
>>
>> diff --git a/manual/Tasks/javadoc.html b/manual/Tasks/javadoc.html
>> index 2f0abe3..0ba51ae 100644
>> --- a/manual/Tasks/javadoc.html
>> +++ b/manual/Tasks/javadoc.html
>> @@ -608,11 +608,11 @@ Same as for package.
>>  Same as one entry in the list given by modulenames.
>>
>>  Parameters
>> -
>> +
>>
>> -Attribute
>> -Description
>> -Required
>> +Attribute
>> +Description
>> +Required
>>
>>
>>  name
>> @@ -871,7 +871,7 @@ See Command line 
>> arguments.
>>group title=Group 2 Packages 
>> packages=com.dummy.test.b*:com.dummy.test.c*/
>>link offline=true 
>> href=https://docs.oracle.com/javase/8/docs/api/; 
>> packagelistLoc=C:\tmp/
>>link href=https://docs.oracle.com/javase/8/docs/api//;
>> -/javadoc
>> +/javadoc
>>
>>  is the same as
>>
>> @@ -894,7 +894,7 @@ See Command line 
>> arguments.
>>group title=Group 2 Packages 
>> packages=com.dummy.test.b*:com.dummy.test.c*/
>>link offline=true 
>> href=https://docs.oracle.com/javase/8/docs/api/; 
>> packagelistLoc=C:\tmp/
>>link href=https://docs.oracle.com/javase/8/docs/api//;
>> -/javadoc
>> +/javadoc
>>
>>  or
>>
>> @@ -917,7 +917,7 @@ See Command line 
>> arguments.
>>group title=Group 2 Packages 
>> packages=com.dummy.test.b*:com.dummy.t

Re: 2.5.0 Release

2019-03-05 Thread Jaikiran Pai
Hello James,

Sorry, I didn't respond earlier. The only thing that's stopping me from
releasing 2.5.0 is IVY-1580 issue. I will send out a mail this week to
dev list to explain what that issue is and what are our options on
getting past it. Once we have a decision, I'll go ahead with a release
proposal.

-Jaikiran

On 02/03/19 1:21 AM, James Broadhead wrote:
> Hi there -
>
> What are the plans for a full 2.5.0 release? It's been a while since the
> release candidate release in April 2018. Are there any release blockers
> that have been discovered?
>
> For context: this is stopping upstream package maintainers shipping 2.5.0,
> as they prefer not to package release candidates. This isn't great for
> users who are on Java 11.
>
> All the best,
>
> James
>

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



Re: JDK 12 enters Rampdown Phase Two

2019-02-18 Thread Jaikiran Pai
Hi Dalibor,

It took me a while to get back to this, but I just gave this a try.
Jacoco has released 0.8.3 version with this fix to support Java 13 and I
gave it a try against the original project which was running into this
issue. I can now confirm that this now works fine with Jacoco 0.8.3 and
Java 13 (even the latest EA 8 build).

-Jaikiran

On 23/01/19 7:00 PM, Jaikiran Pai wrote:
> Hi Dalibor,
>
> On 23/01/19 2:51 PM, Dalibor Topic wrote:
>>
>> On 23.01.2019 08:56, Jaikiran Pai wrote:
>>> Our Ant testsuite against this EA version of JDK 13 has passed fine on
>>> Linux. However, one of our other projects within the Ant umbrella has
>>> shown an issue with the Jacoco library usage (which internally uses ASM
>>> library). Narrowing this down to a simple standalone Java program has
>>> shown that this version of Java isn't compatible with ASM 7.0. It runs
>>> into:
>>>
>>>
>>> java.lang.IllegalArgumentException: Unsupported class file major
>>> version 57
>>>  at org.objectweb.asm.ClassReader.(ClassReader.java:184)
>>>  at org.objectweb.asm.ClassReader.(ClassReader.java:166)
>>>  at org.objectweb.asm.ClassReader.(ClassReader.java:152)
>>>
>>>
>>> while trying to instrument a class compiled with that JDK 13 EA build. I
>>> haven't yet had a chance to see if there's a newer version of ASM which
>>> works against this version, but my quick checks haven't shown any newer
>>> versions.
>> Hi Jaikiran,
>>
>> the changes for experimental support of JDK 13 bytecode have just gone
>> into jacoco, per https://github.com/jacoco/jacoco/pull/835 .
>>
> Thank you for pointing me to that commit, I'll give that snapshot
> version a try against our project and see how it goes, over the next few
> days.
>
> -Jaikiran

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



Re: JDK 12: First Release Candidate available

2019-02-18 Thread Jaikiran Pai
Hello Rory,

Our testsuite, of the master branch of Ant, has come up clean for both
the JDK 12 build 32[1] and JDK 13 build EA 8[2]. These initial test runs
are only against Linux setup and one of these days I'll run these tests
against Windows as well. In the next few days, I'll run some of our
other Ant projects with these JDK builds (especially JDK 12) to make
sure they are fine too.

[1]
https://builds.apache.org/job/Ant%20Master%20(latest%20EA%20JDK)/5/jdk_axis=jdk12-ea,label_exp=ubuntu/

[2]
https://builds.apache.org/job/Ant%20Master%20(latest%20EA%20JDK)/5/jdk_axis=jdk13-ea,label_exp=ubuntu/

-Jaikiran

On 18/02/19 4:55 PM, Rory O'Donnell wrote:
>   Hi Stefan/Jaikiran,
>
> **OpenJDK builds *- JDK 12 Early Access build 32 **is now available
> **at : - jdk.java.net/12/*
> **JDK 12:  First Release Candidate [1]**
>
>  * Per the JDK 12 schedule [2], we are now in Release Candidate Phase.
>  * The stabilization repository, jdk/jdk12, is open for P1 bug fixes
>    per the JDK Release Process (JEP 3) [3].
>  * All changes require approval via the Fix-Request Process [4].
>  *
>    Release note additions since last email
>
>  o
>    Build 31 - can_pop_frame and can_force_early_return capabilities
>    are disabled if JVMCI compiler is used (JDK-8218025
>    <https://bugs.openjdk.java.net/browse/JDK-8218025>) The JVMTI
>    |can_pop_frame| and |can_force_early_return| capabilities are
>    disabled if a JVMCI compiler (like Graal) is used. As a result
>    the corresponding functionality (|PopFrame| and
>    |ForceEarlyReturnXXX| functions) is not available to JVMTI
>    agents. This issue is being fixed via JDK-8218885
>    <https://bugs.openjdk.java.net/browse/JDK-8218885>
>    [https://bugs.openjdk.java.net/browse/JDK-8218885
>    <https://bugs.openjdk.java.net/browse/JDK-8218885>].
>
>  o Build 28: JDK-8212233
>    <https://bugs.openjdk.java.net/browse/JDK-8212233> : javadoc
>    fails on jdk12 with "The code being documented uses modules but
>    the packages defined in $URL are in the unnamed module."
>  * Changes in this build.
>   
> <http://hg.openjdk.java.net/jdk/jdk12/log?rev=reverse%28%22jdk-12%2B31%22%3A%3A%22jdk-12%2B32%22-%22jdk-12%2B31%22%29>
>
> **OpenJDK builds *- JDK 13 Early Access build 8 is **now available
> **at : - jdk.java.net/13/*
>
>  * These early-access, open-source builds are provided under the
>  o GNU General Public License, version 2, with the Classpath
>    Exception <http://openjdk.java.net/legal/gplv2+ce.html>.
>  * Release Notes updates
>  * Build 8
>  o GraphicsEnvironment.getCenterPoint()/getMaximumWindowBounds()
>    are unified across the platforms (JDK-8214918
>    <https://bugs.openjdk.java.net/browse/JDK-8214918>)
>  o The experimental FIPS 140 compliant mode has been removed from
>    the SunJSSE provider. (JDK-8217835
>    <https://bugs.openjdk.java.net/browse/JDK-8217835>)
>  * Build 7
>  o Change DOM parser to not resolve EntityReference and add Text
>    node with
>    DocumentBuilderFactory.setExpandEntityReferences(false)
>    (JDK-8206132 <https://bugs.openjdk.java.net/browse/JDK-8206132>)
>  * Build 6
>  o Base64.Encoder and Base64.Decoder methods can throw
>    OutOfMemoryError (JDK-8210583
>    <https://bugs.openjdk.java.net/browse/JDK-8210583>)
>  * Changes in this build
>   
> <http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-13%2B7%22%3A%3A%22jdk-13%2B8%22-%22jdk-13%2B7%22%29>
>  * FOSS Bugs fixed in recent builds
>  o Build 6 : JDK-8216970
>    <https://bugs.openjdk.java.net/browse/JDK-8216970> : condy
>    causes JVM crash
>  o Build 7: JDK-8215577
>    <https://bugs.openjdk.java.net/browse/JDK-8215577> : Remove
>    javadoc support for HTML 4
>
>
> Rgds,Rory
>
> [1]
> https://mail.openjdk.java.net/pipermail/jdk-dev/2019-February/002623.html
> [2] http://openjdk.java.net/projects/jdk/12/#Schedule
> [3] http://openjdk.java.net/jeps/3
> [4] http://openjdk.java.net/jeps/3#Fix-Request-Process
>

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



Re: How to commit?

2019-02-18 Thread Jaikiran Pai
Hi Craig,

Commits to the repository are only allowed for committers of the
project. For contributing patches (like this one), you can use the
github pull request process. Once reviewed, the merge will then be done
by one of the existing project committers and the contribution will be
credited to you.

-Jaikiran

On 19/02/19 3:04 AM, Craig Pell wrote:
> I have written a working solution for
> <https://bz.apache.org/bugzilla/show_bug.cgi?id=62772> and
> <https://bz.apache.org/bugzilla/show_bug.cgi?id=62789>, the requests
> for the  task to support modular attributes.  My code modifies
> module-info.class directly in the .jar file.  (It actually wasn’t as
> hard as I was expecting it to be.)
>
> I would love to submit the changes, but I’m not clear on how to do it
> using gitbox.  I can clone the codebase easily enough, but I don’t
> know how to get an account there in order to submit changes.
>
> I figured I could just follow the instructions at
> <https://gitbox.apache.org/setup/>, but that requires logging into
> <https://id.apache.org>, which in turn requires an Apache user ID,
> which I don’t seem to have.  When I submitted an ICLA a few months
> ago, I didn’t specify a desired user ID.  I’m now thinking I should
> have, but I’m not sure how to rectify the situation.
>
> From what I’ve been reading, it appears it’s still possible to use
> GitHub, but I’m not certain.  And even if it is possible and
> permissible, I’m not sure whether I should do that, or if I should be
> using gitbox as much as possible now.
>
> -
> 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: JDK 12 enters Rampdown Phase Two

2019-01-23 Thread Jaikiran Pai


Hi Dalibor,

On 23/01/19 2:51 PM, Dalibor Topic wrote:
> 
> 
> On 23.01.2019 08:56, Jaikiran Pai wrote:
>> Our Ant testsuite against this EA version of JDK 13 has passed fine on
>> Linux. However, one of our other projects within the Ant umbrella has
>> shown an issue with the Jacoco library usage (which internally uses ASM
>> library). Narrowing this down to a simple standalone Java program has
>> shown that this version of Java isn't compatible with ASM 7.0. It runs
>> into:
>>
>>
>> java.lang.IllegalArgumentException: Unsupported class file major
>> version 57
>>  at org.objectweb.asm.ClassReader.(ClassReader.java:184)
>>  at org.objectweb.asm.ClassReader.(ClassReader.java:166)
>>  at org.objectweb.asm.ClassReader.(ClassReader.java:152)
>>
>>
>> while trying to instrument a class compiled with that JDK 13 EA build. I
>> haven't yet had a chance to see if there's a newer version of ASM which
>> works against this version, but my quick checks haven't shown any newer
>> versions.
> 
> Hi Jaikiran,
> 
> the changes for experimental support of JDK 13 bytecode have just gone
> into jacoco, per https://github.com/jacoco/jacoco/pull/835 .
> 
Thank you for pointing me to that commit, I'll give that snapshot
version a try against our project and see how it goes, over the next few
days.

-Jaikiran

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



Re: JDK 12 enters Rampdown Phase Two

2019-01-22 Thread Jaikiran Pai
Hi Rory,

On 21/01/19 4:45 PM, Rory O'Donnell wrote:
>  Hi Stefan/Jaikiran,
>
> **OpenJDK builds *- JDK 12 Early Access build 28 **is now available
> **at : - jdk.java.net/12/*
>
Our testsuite on Linux with this EA version of of JDK 12 has passed fine
without issues. Haven't had a chance to test on Windows yet.


>  
> **OpenJDK builds *- JDK 13 Early Access build 4 is **now available
> **at : - jdk.java.net/13/*


Our Ant testsuite against this EA version of JDK 13 has passed fine on
Linux. However, one of our other projects within the Ant umbrella has
shown an issue with the Jacoco library usage (which internally uses ASM
library). Narrowing this down to a simple standalone Java program has
shown that this version of Java isn't compatible with ASM 7.0. It runs into:


java.lang.IllegalArgumentException: Unsupported class file major version 57
    at org.objectweb.asm.ClassReader.(ClassReader.java:184)
    at org.objectweb.asm.ClassReader.(ClassReader.java:166)
    at org.objectweb.asm.ClassReader.(ClassReader.java:152)


while trying to instrument a class compiled with that JDK 13 EA build. I
haven't yet had a chance to see if there's a newer version of ASM which
works against this version, but my quick checks haven't shown any newer
versions.


-Jaikiran



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



Re: [RESULT] [VOTE] Retire Antlib SVN

2019-01-22 Thread Jaikiran Pai
I have followed the retiring guidelines[1] and now done the following to
retire this project:

1. Version control - Added a RETIRED_PROJECT marker file to the (git)
repo https://github.com/apache/ant-antlibs-svn and also updated the
README file of that project to mention the retirement

2. Asked infra to mark the repo read-only, which they promptly did
https://issues.apache.org/jira/browse/INFRA-17728

3. Deleted the Jenkins job for this project from builds.apache.org. I
don't think there's any Teamcity of gump jobs for this project.

4. Removed the homepage of this project (svn revision id 1851821 for
https://svn.apache.org/repos/asf/ant/site/ant/production/antlibs). This
page wasn't linked from anywhere else (as far as I could find).

The process page also has sections for:

1. Issue tracker - N/A for this project since this was tracked in
Bugzilla of Ant project (as far as I know).

2. Mailing list - N/A for this project since dev@ant and user@ant was
used for this project

3. Releases - The process page asks for the releases of the project to
be removed from https://dist.apache.org/repos/dist/release/ant/. I
couldn't find any releases of this project under ant/antlibs folder at
that location. So I don't think we need to do anything here.

4. Announcement - A mail needs to be sent to dev@ant, announce@apache
and the Ant home page needs to be updated with this retirement
announcement. I will do this last, once we confirm there's nothing else
pending.


[1] http://ant.apache.org/processes.html

-Jaikiran

On 22/01/19 7:27 PM, Jaikiran Pai wrote:
> With +1s from Jan, Stefan (and implicitly) me and no other votes, this
> vote has passed. I'll start the process of retiring this project.
>
> -Jaikiran
>
> On 22/12/18 10:51 PM, Stefan Bodewig wrote:
>> On 2018-12-22, Jaikiran Pai wrote:
>>
>>> This is a proposal to retire the "Antlib SVN" library[1]. The project
>>> hasn't seen any new development for many years now[2]. Retiring this
>>> will reduce the work necessary to maintain it[3] (Jekins jobs etc...).
>> +1
>>
>> 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



[RESULT] [VOTE] Retire Antlib SVN

2019-01-22 Thread Jaikiran Pai
With +1s from Jan, Stefan (and implicitly) me and no other votes, this
vote has passed. I'll start the process of retiring this project.

-Jaikiran

On 22/12/18 10:51 PM, Stefan Bodewig wrote:
> On 2018-12-22, Jaikiran Pai wrote:
>
>> This is a proposal to retire the "Antlib SVN" library[1]. The project
>> hasn't seen any new development for many years now[2]. Retiring this
>> will reduce the work necessary to maintain it[3] (Jekins jobs etc...).
> +1
>
> 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



New release?

2019-01-22 Thread Jaikiran Pai
It's been some months now since our last 1.9.x and 1.10.x Ant releases.
During that period, we have added some good number of fixes and
enhancements to both these versions upstream. Some of the users (in
bugzilla discussions) have asked if we can do a release sooner to get
these fixes. As far as I know, there isn't anything pending that needs
to go into this release. Is there any?

Should we do a new release in the upcoming weeks?

-Jaikiran


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



Re: JDK 12 Early Access build 26 & JDK 13 Early Access builds available

2019-01-04 Thread Jaikiran Pai
Hi Rory,

On 04/01/19 3:30 PM, Rory O'Donnell wrote:
> Hi Stefan,
>
> Happy New Year!
>
> *OpenJDK builds *- JDK 12 Early Access build 26 is available at
> http://jdk.java.net/12/
>
Initial run of this EA 26 build on a Linux system has shown no issues in
the Ant project. I haven't had a chance to try this on a Windows system.

-Jaikiran



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



Re: [ant] branch master updated: Update JSCh (see http://www.jcraft.com/jsch/ChangeLog)

2018-12-27 Thread Jaikiran Pai
Hi Stefan,

Thank you for reminding me of those files. I have now pushed a commit in
both the branches which updates these files to use the new version.

-Jaikiran

On 27/12/18 3:04 PM, Stefan Bodewig wrote:
> Hi Jaikiran
>
> you should probably also update manual/install.html as well as the
> affected POMs (in this case src/etc/poms/ant-jsch/pomx.xml) for
> consistency.
>
> 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: [RESULT] move over to gitbox.apache.org

2018-12-23 Thread Jaikiran Pai
On 17/12/18 2:25 PM, Stefan Bodewig wrote:
> On 2018-12-17, Jaikiran Pai wrote:
>
>> On 17/12/18 2:09 PM, Stefan Bodewig wrote:
>>> I will take care of Gump, if anybody else could look into Jenkins that
>>> would be great.
>> I'll take a look at the Jenkins jobs later tonight and update them as
>> necessary.
> Thank you. I've also updated the main Ant site but have no idea how the
> Ivy and IvyDE sites are generated so kept away from them.

I have updated the Ivy site to refer to gitbox. It should be live now.
The IvyDE site didn't have any references to the git repository
locations, so there wasn't anything I had to do in this context.

-Jaikiran


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



Commit notifications from gitbox [was [ant] branch master updated (706d818 -> 722ccb7)]

2018-12-21 Thread Jaikiran Pai
Adding us...@infra.apache.org. Comments inline.

On 21/12/18 1:01 AM, bode...@apache.org wrote:
> This is an automated email from the ASF dual-hosted git repository.
>
> bodewig pushed a change to branch master
> in repository https://gitbox.apache.org/repos/asf/ant.git.
>
>
> from 706d818  moved to gitbox
>  add 82a603c  Use valid markup
>  new 722ccb7  Merge pull request #82 from twogee/invalid-html
>
> The 1 revisions listed above as "new" are entirely new to this
> repository and will be described in separate emails.  The revisions
> listed as "add" were already present in the repository and have only
> been added to this reference.

This looks a bit odd. The "Use valid markup" is a new commit and wasn't
there in the upstream repository previously, so not sure why it's being
considered as already present.

Furthermore, the other mail notification which contained the details
about the "new" just listed the files that changed and the line count of
changes. Previously, when we were on git.wip-us repo, these
notifications used to inline the diff within one or more emails and that
format was very convenient to do reviews. Would it be possible to have a
similar format (at least for Ant project(s)) for these notifications?

-Jaikiran


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



Re: [VOTE] Retire Antlib SVN

2018-12-21 Thread Jaikiran Pai
An implicit +1.

-Jaikiran


On 22/12/18 7:39 AM, Jaikiran Pai wrote:
> This is a proposal to retire the "Antlib SVN" library[1]. The project
> hasn't seen any new development for many years now[2]. Retiring this
> will reduce the work necessary to maintain it[3] (Jekins jobs etc...).
>
> More about retiring a project or a project component can be found here[4].
>
>
> [1] http://ant.apache.org/antlibs/svn/
>
> [2] https://github.com/apache/ant-antlibs-svn/commits/master
>
> [3]
> https://mail-archives.apache.org/mod_mbox/ant-dev/201812.mbox/%3c87k1k5wg7a@v45346.1blu.de%3e
>
> [4] http://ant.apache.org/processes.html
>
> -Jaikiran
>
>


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



[VOTE] Retire Antlib SVN

2018-12-21 Thread Jaikiran Pai
This is a proposal to retire the "Antlib SVN" library[1]. The project
hasn't seen any new development for many years now[2]. Retiring this
will reduce the work necessary to maintain it[3] (Jekins jobs etc...).

More about retiring a project or a project component can be found here[4].


[1] http://ant.apache.org/antlibs/svn/

[2] https://github.com/apache/ant-antlibs-svn/commits/master

[3]
https://mail-archives.apache.org/mod_mbox/ant-dev/201812.mbox/%3c87k1k5wg7a@v45346.1blu.de%3e

[4] http://ant.apache.org/processes.html

-Jaikiran



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



Re: Antlib SVN and antunit Java versions

2018-12-20 Thread Jaikiran Pai


On 19/12/18 11:29 PM, Stefan Bodewig wrote:
> On 2018-12-18, Jaikiran Pai wrote:
>
>> One option in similar cases that we have employed in other jobs is to
>> configure the Java system property -Dhttps.protocols to "TLSv1.2". But
>> this version of TLS is only supported in a Java release after Java 1.5.
> I'd be in favor of updating the jobs. Nobody would build releases using
> Java 1.5 either, I guess.
Done. I have updated the jobs of antlib svn and antunit to use Java 8 to
build it.

>
>> At a more higher level, I think it's probably time to decide whether we
>> want to change the minimum required Java versions for these libraries?
>> Should we now mandate Java 1.8 at least?
> In the case of antlib svn we could simply decide to call it dead or
> dormant or whatever (like almost all other antlibs, I guess). Unless I'm
> overlooking something, the svn antlib is neither listed on
> http://ant.apache.org/antlibs/proper.html nor
> http://ant.apache.org/antlibs/sandbox.html - so it doesn't even exist
> from out user's point of view.
I found this (live) page http://ant.apache.org/antlibs/svn/ the other
day while looking at the Jenkins failure. But now that you mention it, I
don't remember how I landed up on that page. I don't see it linked in
the Jenkins job or some other place. But yes, I don't see it linked
anywhere in the Ant website. I'll start a new VOTE thread to retire this
project. I might need Jan's help here if/after the VOTE passes to
actually do some of the process involved in retiring projects.

-Jaikiran




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



Antlib SVN and antunit Java versions

2018-12-18 Thread Jaikiran Pai
While looking at some of our Jenkins jobs, to reconfigure them to use
gitbox (wherever necessary), I notice that there are 2 jobs[1][2] which
are for Antlib SVN and Antunit libraries. Both these jobs are configure
for JDK 5, because those projects target Java 5 as the minimal runtime.
However, the Maven central repo, from which we fetch certain
dependencies during build has been configured not to let clients with
lower TLS versions (lesser than TLSv1.2) to communicate with it. As a
result they are now failing. The issue has been around for a while with
these jobs, it's just that they haven't run for a few months until
yesterday.

One option in similar cases that we have employed in other jobs is to
configure the Java system property -Dhttps.protocols to "TLSv1.2". But
this version of TLS is only supported in a Java release after Java 1.5.
In short, unless we upgrade the Java runtime version of these jobs (or
do some very specific tricks to use a different Java version while
pulling down the dependencies in the build), they will continue failing.

At a more higher level, I think it's probably time to decide whether we
want to change the minimum required Java versions for these libraries?
Should we now mandate Java 1.8 at least?


[1] https://builds.apache.org/job/AntLib-svn/

[2] https://builds.apache.org/job/AntLib-antunit/


-Jaikiran



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



Re: [RESULT] move over to gitbox.apache.org

2018-12-17 Thread Jaikiran Pai



On 17/12/18 2:09 PM, Stefan Bodewig wrote:
> I will take care of Gump, if anybody else could look into Jenkins that
> would be great. 
I'll take a look at the Jenkins jobs later tonight and update them as
necessary.

-Jaikiran

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



[GitHub] ant pull request #80: Added tasks for JDK's jmod and jlink tools.

2018-12-11 Thread jaikiran
Github user jaikiran commented on a diff in the pull request:

https://github.com/apache/ant/pull/80#discussion_r240889855
  
--- Diff: src/main/org/apache/tools/ant/taskdefs/modules/Jmod.java ---
@@ -0,0 +1,1282 @@
+/*
+ *  Licensed to the Apache Software Foundation (ASF) under one or more
+ *  contributor license agreements.  See the NOTICE file distributed with
+ *  this work for additional information regarding copyright ownership.
+ *  The ASF licenses this file to You under the Apache License, Version 2.0
+ *  (the "License"); you may not use this file except in compliance with
+ *  the License.  You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ *  Unless required by applicable law or agreed to in writing, software
+ *  distributed under the License is distributed on an "AS IS" BASIS,
+ *  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or 
implied.
+ *  See the License for the specific language governing permissions and
+ *  limitations under the License.
+ *
+ */
+
+package org.apache.tools.ant.taskdefs.modules;
+
+import java.io.File;
+import java.io.ByteArrayOutputStream;
+import java.io.PrintStream;
+import java.io.IOException;
+
+import java.nio.file.Files;
+
+import java.util.Collection;
+import java.util.List;
+import java.util.ArrayList;
+
+import java.util.Map;
+import java.util.LinkedHashMap;
+
+import java.util.Collections;
+
+import java.util.spi.ToolProvider;
+
+import org.apache.tools.ant.BuildException;
+import org.apache.tools.ant.Project;
+import org.apache.tools.ant.Task;
+
+import org.apache.tools.ant.util.MergingMapper;
+import org.apache.tools.ant.util.FileUtils;
+import org.apache.tools.ant.util.ResourceUtils;
+
+import org.apache.tools.ant.types.EnumeratedAttribute;
+import org.apache.tools.ant.types.FileSet;
+import org.apache.tools.ant.types.ModuleVersion;
+import org.apache.tools.ant.types.Path;
+import org.apache.tools.ant.types.Reference;
+import org.apache.tools.ant.types.Resource;
+import org.apache.tools.ant.types.ResourceCollection;
+
+import org.apache.tools.ant.types.resources.FileResource;
+import org.apache.tools.ant.types.resources.Union;
+
+/**
+ * Creates a linkable .jmod file from a modular jar file, and optionally 
from
+ * other resource files such as native libraries and documents.  Equivalent
+ * to the JDK's
+ * https://docs.oracle.com/en/java/javase/11/tools/jmod.html;>jmod
+ * tool.
+ * 
+ * Supported attributes:
+ * 
+ * {@code destFile}
+ * Required, jmod file to create.
+ * {@code classpath}
+ * {@code classpathref}
+ * Where to locate files to be placed in the jmod file.
+ * {@code modulepath}
+ * {@code modulepathref}
+ * Where to locate dependencies.
+ * {@code commandpath}
+ * {@code commandpathref}
+ * Directories containing native commands to include in jmod.
+ * {@code headerpath}
+ * {@code headerpathref}
+ * Directories containing header files to include in jmod.
+ * {@code configpath}
+ * {@code configpathref}
+ * Directories containing user-editable configuration files
+ * to include in jmod.
+ * {@code legalpath}
+ * {@code legalpathref}
+ * Directories containing legal licenses and notices to include in 
jmod.
+ * {@code nativelibpath}
+ * {@code nativelibpathref}
+ * Directories containing native libraries to include in jmod.
+ * {@code manpath}
+ * {@code manpathref}
+ * Directories containing man pages to include in jmod.
+ * {@code version}
+ * Module https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/module/ModuleDescriptor.Version.html;>version.
+ * {@code mainclass}
+ * Main class of module.
+ * {@code platform}
+ * The target platform for the jmod.  A particular JDK's platform
+ * can be seen by running
+ * jmod describe $JDK_HOME/jmods/java.base.jmod | grep -i 
platform.
+ * {@code hashModulesPattern}
+ * Regular expression for names of modules in the module path
+ * which depend on the jmod being created, and which should have
+ * hashes generated for them and included in the new jmod.
+ * {@code resolveByDefault}
+ * Boolean indicating whether the jmod should be one of
+ * the default resolved modules in an application.  Default is true.
+ * {@code moduleWarnings}
+ * Whether to emit warnings when resolving modules which are
+ * not recommended for use.  Comma-separated list of one of more of
+ * the following:
+ * 
+ * {@code deprecated}
+ * Warn if module is deprecated
+ * {@code leaving}
+ * Wa

[GitHub] ant issue #81: Fix rare ConcurrentModificationException when running with Pa...

2018-12-11 Thread jaikiran
Github user jaikiran commented on the issue:

https://github.com/apache/ant/pull/81
  
@mharmer, what name would you like us to add to our contributors list 
(https://github.com/apache/ant/blob/master/CONTRIBUTORS) for your contribution? 


---

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



[GitHub] ant issue #81: Fix rare ConcurrentModificationException when running with Pa...

2018-12-11 Thread jaikiran
Github user jaikiran commented on the issue:

https://github.com/apache/ant/pull/81
  
> @jaikiran I think the test does exhibit the multithreaded scenario, I ran 
it prior to the Project changes to ensure it did fail. My Java is a bit rusty, 
but I believe the 2 separate ExecutorService's created run concurrently.

You are right indeed. When I replied previously, I did not focus on the 
second executor submit and the fact that this task would run in parallel with 
the previous for loop that (might) still be in progress.

> My only concern is it's possible it may not catch the issue in the future 
as a regression test due to the non-determinism, as well as the somewhat 
arbitrary loop count and extended time taken to run the test (<100 milliseconds 
currently, but overall these types of tests tend to add up).

Agreed. So it's fine to not include the test.


---

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



[GitHub] ant issue #81: Fix rare ConcurrentModificationException when running with Pa...

2018-12-11 Thread jaikiran
Github user jaikiran commented on the issue:

https://github.com/apache/ant/pull/81
  
I don't have enough knowledge about the thread safety aspects of the 
`Project` class. Stefan (@bodewig) would know more. However, having look at its 
code, I see similar locks and thread safety constructs for other members, so I 
think this change is fine.

As for the testcase, I think it's OK to add one. However, the snippet that 
you pasted might need some work. Right now, it uses a single thread and then in 
that thread's execution runs the APIs of the `Project` class in a loop. So it 
really doesn't exercise the multi-thread access behaviour and the access will 
all be sequential. What you could do is, use a fixed thread pool with a decent 
size (10 perhaps) and then use a loop (of 10) to submit the 
`p.CopyOfReferences` in that loop and finally `get()` the result for each of 
those `Future`s.



---

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



[GitHub] ant issue #81: Fix rare ConcurrentModificationException when running with Pa...

2018-12-11 Thread jaikiran
Github user jaikiran commented on the issue:

https://github.com/apache/ant/pull/81
  
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: ant git commit: bz-62952 Make AntClassLoader multi-release jar aware when it deals with java.util.jar.JarFile

2018-12-09 Thread Jaikiran Pai
Hi Stefan,


On 09/12/18 3:18 PM, Stefan Bodewig wrote:
> On 2018-12-05,  wrote:
>
>> Repository: ant
>> Updated Branches:
>>   refs/heads/master ac46ff190 -> 593aff2d2
>
>> bz-62952 Make AntClassLoader multi-release jar aware when it deals with 
>> java.util.jar.JarFile
> An alternative approach to using reflection when creating the JarFile
> instance would be to create different AntClassLoader instances. We did
> so for Java 2.x and Java 5.x respectively when the baselines were 1.1 or
> anything lower than 1.5.
>
> https://github.com/apache/ant/commit/17527b6490851a728623c1dcbf5078cc63a982dd
> is the commit where I reverted the logic for the Java5 specific
> classloader after Java5 became the baseline.

I did check it out before going with this approach. I decided to go with
this approach because at this point, for just this change, this looked a
bit more simpler than having to introduce the new classloader which then
would have to use the new Java 9 JarFile API at compile time and would
involve build file updates.
>
> I'm not sure it makes any difference right now but can imagine the
> classloader will have to learn some additional tricks for module support
> in the future.

Agreed, I haven't yet checked what more will be expected of classloader
post Java 9 but if it looks like better approach to lay the ground work
and create a new classloader instead of this reflection approach, I am
open to it.

-Jaikiran


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



Re: [VOTE] move over to gitbox.apache.org

2018-12-07 Thread Jaikiran Pai
+1 for the move.

-Jaikiran


On 07/12/18 10:29 PM, Stefan Bodewig wrote:
> Hi all
>
> as indicated by Daniel we'll have to mover over sooner rather than later
> anyway. So we may better do so now with no release in sight.
>
> Any objections or do we want to go ahead?
>
> 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



[GitHub] ant issue #80: Added tasks for JDK's jmod and jlink tools.

2018-12-06 Thread jaikiran
Github user jaikiran commented on the issue:

https://github.com/apache/ant/pull/80
  
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: ant git commit: bz-62890 Make sure the sync task considers the case sensitivity of the destination directory's filesystem while looking for orphan files to delete

2018-11-12 Thread Jaikiran Pai
Hi Stefan,

On 12/11/18 11:26 PM, Stefan Bodewig wrote:
> On 2018-11-08,  wrote:
>
>> +private static final Map fileSystemCaseSensitivity 
>> = new HashMap<>();
> I understand it may be expensive to determine whether a filesystem is
> case-sensitive, but I'm a bit hesitant about the cache as it never gets
> cleared if things run for a long time.
That's a good point. I hadn't thought about it. You are right, this can
lead to the cache growing without being cleared. I will remove this
caching. The javadoc of this new method already states that it might
create new file, so I think that's probably enough to hint that this
method could be expensive, so I won't add anything new to it.

-Jaikiran

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



[GitHub] ant issue #76: bz-43144 - Improve the performance of the tar task when it us...

2018-11-06 Thread jaikiran
Github user jaikiran commented on the issue:

https://github.com/apache/ant/pull/76
  
>> Looks as if you had found a solution with minimal API impact that can be 
extended to cases other than just tar although I'm afraid we are using resource 
collections wrapping resource collections in some places.

You are right, plus unlike the `tar` task, the way `Resource`(s) are passed 
around, it isn't that straightforward to keep track of them. I might still find 
a way similar to this to get those covered too. I'll spend some more time on 
this in the upcoming days.


---

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



[GitHub] ant issue #76: bz-43144 - Improve the performance of the tar task when it us...

2018-11-01 Thread jaikiran
Github user jaikiran commented on the issue:

https://github.com/apache/ant/pull/76
  
I'm going to put this on hold for a bit and won't merge it yet, for the 
reasons noted in the recent comments in the linked issue. 


---

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



[GitHub] ant pull request #76: bz-43144 - Improve the performance of the tar task whe...

2018-11-01 Thread jaikiran
Github user jaikiran closed the pull request at:

https://github.com/apache/ant/pull/76


---

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



[GitHub] ant pull request #:

2018-11-01 Thread jaikiran
Github user jaikiran commented on the pull request:


https://github.com/apache/ant/commit/0cb9d22b77dda1dcabba91d4c2a1616d0042d16c#commitcomment-31143975
  
In 
src/main/org/apache/tools/ant/taskdefs/optional/junitlauncher/StandaloneLauncher.java:
In 
src/main/org/apache/tools/ant/taskdefs/optional/junitlauncher/StandaloneLauncher.java
 on line 255:
That field indeed is no longer used. I have pushed a commit to remove it.


---

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



[GitHub] ant pull request #76: bz-43144 - Improve the performance of the tar task whe...

2018-10-31 Thread jaikiran
GitHub user jaikiran opened a pull request:

https://github.com/apache/ant/pull/76

bz-43144 - Improve the performance of the tar task when it uses a zipfileset

https://bz.apache.org/bugzilla/show_bug.cgi?id=43144 is an issue where 
users have reported that the tar task is extremely slow when used with a 
`zipfileset`. 

The comment in that bug, from @bodewig, rightly notes that the reason for 
this slowness has to do with the code where we iterate over the zip entries as 
a `Resource` and then open an `InputStream` for each entry during the `tar` 
task. The implementation of the `ZipResource#getInputStream` opens a new 
`ZipFile` every time and as Stefan notes in that bug, the reason it's done this 
way is because we don't know what would be the right time to close a `ZipFIle` 
if the implementation of the `ZipResource` would want to hold on to a open 
`ZipFile` instance and reuse it.

However, there are occasions, like the one here, where the callers of the 
`ArchiveFileSet` are aware and know when and how long they expect the 
underlying archive to be open. The commit in this PR, introduces a new method 
(`openArchive()`) on the `ArchiveFileSet` to allow such callers to have more 
control over the opening and closing of the underlying resource(s) like the 
`ZipFile`. The whole goal of this new method is to allow iterating over the 
entries in the archive (just like the existing `iterator()` method) and yet the 
same time exposing a way for users to explicitly `close` the returned 
`ArchiveEntries`. When to use the `iterator()` method and when to use the 
`openArchive` method will be left to the users of ArchiveSet.

The commit in this PR intentionally just exposes only one method 
`openArchive` as a `public` method and keeps the rest of the new methods either 
private or package private. Right now, only `ZipFileSet` overrides the new 
package private method to provide a scanner which holds on to open resource(s), 
if it's asked to do so.

The changes in this commit maintain backward compatibility of the existing 
methods and does _not_ introduce any change in behaviour of their usages or 
semantics.

The javadocs of the new methods explain more about what each one does and 
how the usage typically looks like.

I have run a few of the existing Tar related tests locally and haven't 
found any regressions. I have also run a manual test to see how the new 
performance with this change looks like. I used a random zip file which is 
around 5MB in size and has 927 entries (as reported by the unzip command):

```
unzip -l source.zip
 
- ---
 2385 927 files
```
I then used the following build file:

```




  

   


```
Ran the following command:
```
time ant
```
With Ant 1.10.5 (the latest released), it takes a while to complete and 
reports:

```
Total time: 23 seconds

real0m23.485s
user0m16.767s
sys 0m9.368s
```
So around 23 seconds for the tar task.

With this patch and the freshly built Ant distribution, this same build 
file (I did the necessary cleanup of the  build generated tar file, before 
running it again) reports:

```
Total time: 0 seconds

real0m1.068s
user0m1.994s
sys 0m0.258s
```

Around 1 second for the exact same task. So as expected there's a big 
improvement. I have done basic comparison of the generated tar files, with Ant 
1.10.5 and this patched version to check it contains all the expected content 
and it looked fine. I will see if I can add some kind of automated testing 
around this if possible. Until then I would like inputs on whether this looks 
fine and any suggestions/feedback on this change. Right now, this is targetted 
for master branch. I'll take a look later if it's easy (I guess, should be) to 
have this in 1.9.x too.

P.S: The linked bug also has one comment which states that the `copy` task 
when it uses a `zipfileset` is impacted by this performance issue too. I 
haven't checked or verified that. At a later date, I'll take a look if it needs 
this same/similar fix.



 

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/jaikiran/ant bz-43144-master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ant/pull/76.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #76


commit 81b8c80c550ba560770a1f82de60c4d0b11ace91
Author: Jaikiran Pai 
Date:   2018-10-31T13:59:29Z

bz-43144 - (performance fix) Explicitly control when an archive is opened 
and closed when a zipfileset is used

[GitHub] ant pull request #69: Allow more control over location of JUnit libraries fo...

2018-10-29 Thread jaikiran
Github user jaikiran closed the pull request at:

https://github.com/apache/ant/pull/69


---

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



[GitHub] ant issue #69: Allow more control over location of JUnit libraries for users...

2018-10-29 Thread jaikiran
Github user jaikiran commented on the issue:

https://github.com/apache/ant/pull/69
  
Thanks Stefan. I'll go ahead and merge this today and include a note in 
WHATSNEW.


---

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



[GitHub] ant issue #69: Allow more control over location of JUnit libraries for users...

2018-10-23 Thread jaikiran
Github user jaikiran commented on the issue:

https://github.com/apache/ant/pull/69
  
I'll merge this one tomorrow if there aren't any objections. However, even 
after this being merged, I'm open for any suggestions/review about this change.



---

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



Re: Tests in Surefire

2018-10-21 Thread Jaikiran Pai
Could you tell us a bit more about what is being attempted? Are you
saying you plan to run the tests that are part of the Ant project,
through the mvn command, while building Ant?

-Jaikiran


On 20/10/18 3:31 PM, Gintautas Grigelionis wrote:
> I believe that in order to execute Ant test suite in Surefire one must
> configure basedir which unfortunately affects Ant test projects. Perhaps it
> would make sense to have a magic property that (in combination with
> detection of Surefire environment) would allow BuildFileRule to call
> System.clearProperty("basedir")?
>
> Gintas
>


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



[GitHub] ant issue #69: Allow more control over JUnit libraries and Ant runtime libra...

2018-10-11 Thread jaikiran
Github user jaikiran commented on the issue:

https://github.com/apache/ant/pull/69
  
The build actually caught a genuine issue that this build.xml was meant to 
catch. I have now added a 3rd commit to this PR which fixes that issue. I'll be 
squashing these commits before merging, if/when these changes are approved.



---

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



[GitHub] ant issue #69: Allow more control over JUnit libraries and Ant runtime libra...

2018-10-11 Thread jaikiran
Github user jaikiran commented on the issue:

https://github.com/apache/ant/pull/69
  
The build.xml changes that I committed look a bit wrong. Fixing them to a 
working version.


---

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



[GitHub] ant pull request #69: Allow more control over JUnit libraries and Ant runtim...

2018-10-11 Thread jaikiran
GitHub user jaikiran opened a pull request:

https://github.com/apache/ant/pull/69

Allow more control over JUnit libraries and Ant runtime libraries for users 
of junitlauncher

I've been sitting on these changes for a while now trying to complete this 
work and then get some inputs. But I think these changes have now reached a 
state where I can get some feedback for them.

**Background**

1.10.3 of Ant introduced support for using JUnit 5 through the new 
`junitlauncher` task. The support was minimal but had enough features for users 
to get started with using JUnit 5. 

JUnit 5 project divides the JUnit libraries into `platform`, `launcher` and 
`engine` libraries. Ant's `junitlauncher` task relies only on JUnit `platform` 
and `launcher` libraries to support  launching the tests. The `engine` 
libraries are allowed to be part of the task's classpath (configured via the 
`classpath` element). Unlike for the `engine` libraries, the `junitlauncher` 
task requires the JUnit `platform` and `launcher` libraries to be part of the 
Ant runtime classpath (either in the Ant installation directories or by using 
the `-lib` option while launching Ant).  Historically, as seen with `junit` 
task, users prefer more control over the location of these jars while running 
their tests. 

**Goal**

The goal of the commit(s) in this PR is to allow users to configure a 
classpath for the `junitlauncher` task with the necessary `platform`, 
`launcher` JUnit libraries and not force them to place these jars in the Ant 
runtime classpath.

Imagine something like:

```














  
  




```
and then just run the build as:

```
ant test
```
without any explicit `-lib` nor the necessity to place the JUnit libraries 
in the Ant installation directory.

**Overview of changes**

Changes in this PR borrow ideas from the `junit` task and at the same time 
try and keep the complexity of this task manageable. This PR has 2 commits. One 
is solely in the build file and can be discussed/reviewed separately. I'll 
explain the build changes later in this PR. The main change in this PR is the 
commit which refactors the existing code. What that commit does is separates 
out the classes that are part of the `junitlauncher` task into 2 separate 
packages. 

The `org.apache.tools.ant.taskdefs.optional.junitlauncher.confined` package 
as noted in its `package-info.java` documentation is _not_ allowed to have any 
_compile_ time dependency on the classes in 
`org.apache.tools.ant.taskdefs.optional.junitlauncher` or any of the classes in 
JUnit libraries. This allows the implementation of the task to load the JUnit 
libraries or any classes that depend on those libraries in a way that those 
classes don't have to be on the runtime classpath of Ant when the build is 
launched (see `TaskConfiguredPathClassLoader` in this PR and its usage for 
details). 

On the other hand, the  classes in the 
`org.apache.tools.ant.taskdefs.optional.junitlauncher` are allowed to have 
compile time dependency on classes in 
`org.apache.tools.ant.taskdefs.optional.junitlauncher.confined` or any classes 
that belong to JUnit libraries. Most the "core" logic of launching the tests 
happens in this package.

The commits in this PR are only refactoring changes to get this working. 
These do not contain any logic changes to the currently supported features of 
junitlauncher task. Although these refactoring changes do touch some 
classes/code that's meant to deal with `fork` mode support, none of these 
changes have any impact on the current functionality of how `fork` mode is 
implemented. In fact, the classloading changes that are described and 
implemented here play no role, if the `junitlauncher` task is configured to use 
`fork` mode.

**Backward compatibility**

One unfortunate but unavoidable change that I had to do was move the 
`JUnitLauncherTask` class (among some others) from 
`org.apache.tools.ant.taskdefs.optional.junitlauncher` to 
`org.apache.tools.ant.taskdefs.optional.junitlauncher.confined` package. This 
effectively means that if there was anyone out there who were relying on this 
class (out side of the task usage in the build file itself) will start running 
into issue. I need input on this part (among other things in this PR) - are we 
allowed to do such changes and add a backward compatiblity note in our release 
notes?

**Build file change**

The commit in this PR which deals with the build file, updates the `build` 
task to add a `verification` check (to be extra careful) to ensure that the 
classes in the `org.apache.tools.ant.taskdefs.optional.junitlauncher.confined` 
package have no compile time dependency on JUnit

Re: AW: Java 11 Compatibility Problem

2018-10-10 Thread Jaikiran Pai
Hi Jan,

For end users (of Ivy), the place where pack200 packaging becomes
visible is when they reference it in their dependencies as noted in our
doc[1]. So IMO, I think we should probably add a note/warning within our
documentation than a runtime log/warn message. But I still think, it's a
bit too early to do that. Maybe we should wait a few more releases of
Java and see if any alternatives show up?

[1]
https://ant.apache.org/ivy/history/latest-milestone/concept.html#packaging

-Jaikiran
On 10/10/18 11:09 AM, Jan Matèrne (jhm) wrote:
> If I understand Dragans point right, the warning comes when analyzing the 
> code.
> Not just running Ivy.
> So the normal user won't see the warning. Maybe we should implement a warning?
>
> Jan
>
>> -Ursprüngliche Nachricht-
>> Von: Jaikiran Pai [mailto:jaiki...@apache.org]
>> Gesendet: Mittwoch, 10. Oktober 2018 07:08
>> An: dev@ant.apache.org
>> Betreff: Re: Java 11 Compatibility Problem
>>
>> I agree with Stefan, at the moment I recommend ignoring those warnings.
>> There isn't anything else we can do (other than removing support for
>> pack200, which isn't a good option).
>>
>> -Jaikiran
>>
>>
>> On 10/10/18 9:56 AM, Stefan Bodewig wrote:
>>> Hi Krzysztof
>>>
>>> I'm not actively working on Ivy so take my response with a grain of
>>> salt.
>>>
>>> On 2018-10-09, Dragan, Krzysztof wrote:
>>>
>>>> Hi,
>>>> scanning latest version of Apache Ivy(2.5.0-rc-1) using jdeprscan on
>>>> jdk11 I noticed two problems with this jar.
>>>> These two methods using internal jdk marked for removal and will be
>> deleted:
>>>>   * class org/apache/ivy/util/FileUtil uses deprecated class
>>>> java/util/jar/Pack200$Unpacker (forRemoval=true)
>>>>   * class org/apache/ivy/util/FileUtil uses deprecated class
>>>> java/util/jar/Pack200 (forRemoval=true)
>>> For background see https://openjdk.java.net/jeps/336
>>>
>>> The Java community has decided to eventually remove support for the
>>> pack200 format, but it still is there in Java11. Right now this is
>>> only a warning, it will only become a real problem once the classes
>>> actually get removed. They do not offer any alternative
>> implementation
>>> right now, and may never do (unlike the JAXB case, which is available
>>> as an external library now).
>>>
>>> I am aware of an alternative based on the former Apache Harmony code
>>> in https://github.com/pfirmstone/pack200 but am unsure about its
>> state
>>> - both technically and legally - I very vaguely recall the Pack200
>>> spec was encumbered with Oracle patents but may be totally wrong.
>>>
>>> In Ivy's case the only save option right now was to remove support
>> for
>>> pack200 archives and break existing setups that consume such archives
>>> which seems to be excessive just in order to get rid of a warning.
>>>
>>> If yu ask me I'd recommend to live with the warning for now and wait
>>> for an alternative to the class library's pack200 classes to become
>>> available - which hopefully happens before the Java version removing
>>> support gets released.
>>>
>>> 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
>


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



Re: Java 11 Compatibility Problem

2018-10-09 Thread Jaikiran Pai
I agree with Stefan, at the moment I recommend ignoring those warnings.
There isn't anything else we can do (other than removing support for
pack200, which isn't a good option).

-Jaikiran


On 10/10/18 9:56 AM, Stefan Bodewig wrote:
> Hi Krzysztof
>
> I'm not actively working on Ivy so take my response with a grain of
> salt.
>
> On 2018-10-09, Dragan, Krzysztof wrote:
>
>> Hi,
>> scanning latest version of Apache Ivy(2.5.0-rc-1) using jdeprscan on
>> jdk11 I noticed two problems with this jar.
>> These two methods using internal jdk marked for removal and will be deleted:
>>   * class org/apache/ivy/util/FileUtil uses deprecated class
>> java/util/jar/Pack200$Unpacker (forRemoval=true)
>>   * class org/apache/ivy/util/FileUtil uses deprecated class
>> java/util/jar/Pack200 (forRemoval=true)
> For background see https://openjdk.java.net/jeps/336
>
> The Java community has decided to eventually remove support for the
> pack200 format, but it still is there in Java11. Right now this is only
> a warning, it will only become a real problem once the classes actually
> get removed. They do not offer any alternative implementation right now,
> and may never do (unlike the JAXB case, which is available as an
> external library now).
>
> I am aware of an alternative based on the former Apache Harmony code in
> https://github.com/pfirmstone/pack200 but am unsure about its state -
> both technically and legally - I very vaguely recall the Pack200 spec
> was encumbered with Oracle patents but may be totally wrong.
>
> In Ivy's case the only save option right now was to remove support for
> pack200 archives and break existing setups that consume such archives
> which seems to be excessive just in order to get rid of a warning.
>
> If yu ask me I'd recommend to live with the warning for now and wait for
> an alternative to the class library's pack200 classes to become
> available - which hopefully happens before the Java version removing
> support gets released.
>
> 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: p2.mirrorsURL and p2-mirrors--xml.cgi causing problems on update site

2018-10-04 Thread Jaikiran Pai
Hello Basil,

Sorry about the delayed response. I did notice your other mail in the
user mailing list. Unfortunately I'm not an expert in this area, so
haven't been able to respond sooner. I don't yet have an answer/fix for
you, but I'm now looking into this and will seek some help from others.

-Jaikiran


On 29/09/18 1:28 AM, Basil Crow wrote:
> Hi all,
>
> Please forgive the cross-post from ivy-user, but I didn't get a reply
> there after waiting for a week. If there is some other forum I should
> be using to report this issue, please let me know.
>
> I have a custom Eclipse IDE build using Ant which fetches the Ivy
> feature group using a P2 mirror Ant task:
>
> 
>  location="file:downloads/org.apache.ivy.feature.feature.group-2.4.0.final_20141213170938"/>
> 
>  location="http://www.apache.org/dist/ant/ivyde/updatesite"/>
> 
>  version="2.4.0.final_20141213170938"/>
> 
> 
>
> Unfortunately, this task started failing with the following error:
>
> [p2.mirror] [Fatal Error]
> p2-mirrors--xml.cgi?path=ivy-2.4.0.final_20141213170938==0=xml:39:3:
> The element type "link" must be terminated by the matching end-tag "".
> [p2.mirror] [Fatal Error]
> p2-mirrors--xml.cgi?path=ivy-2.4.0.final_20141213170938==0=xml:39:3:
> The element type "link" must be terminated by the matching end-tag "".
> [p2.mirror] Messages while mirroring artifact descriptors.
>
> I tried setting the Java property eclipse.p2.mirrors=false, but this
> did not help.
>
> Looking at "artifacts.xml" [1], there is a property named
> "p2.mirrorsURL" that points to "p2-mirrors--xml.cgi" [2], which is the
> same URL from the error message above. Visiting that URL in my browser
> says: "The requested file or directory is not on the mirrors."
>
> Can the update site please be fixed so that I can mirror the P2
> repository with Ant?
>
> Thanks,
> Basil
>
> [1] 
> http://www.apache.org/dist/ant/ivyde/updatesite/ivy-2.4.0.final_20141213170938/artifacts.xml
> [2] 
> http://ant.apache.org/ivy/ivyde/updatesite/p2-mirrors--xml.cgi?path=ivy-2.4.0.final_20141213170938
>
> -
> 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: new release

2018-09-11 Thread Jaikiran Pai
Hi Simon,


On 11/09/18 3:40 PM, Simon IJskes - QCG wrote:
> I know of at least
>
> https://bz.apache.org/bugzilla/show_bug.cgi?id=62621
>
> was fixed, by you (thanks!), was this the only one?
There have been other bug fixes too, but I wasn't sure if you were
interested in some other unresolved issue and hence asked that question.

>
> I remember it used to be quite labor intensive, doing a release, so i
> can understand if it wont be done now.
I'm almost in the final phases of getting the junitlauncher task to
support fork mode as well as better handling of classpath for 1.10.x
version. I hope to send out a PR for review this week and if it gets
accepted then I don't have anything else pending from a release point of
view.

-Jaikiran

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



Re: ant git commit: Check spelling

2018-09-11 Thread Jaikiran Pai
After all the numerous mail discussions that we have gone through over
this last year about commits like these, are you seriously asking what's
the difference between [1] and [2]? It's attitude and questions like
this that makes me wonder if you are willingly trolling the project or
if I have completely lost my mind and perspective of what adds value to
the project and what doesn't and instead ended up being a grumpy and
frustrated broken record and whether all these efforts to stop this is
really worth it.

[1] https://github.com/apache/ant/pull/66/files

[2]
https://github.com/apache/ant/commit/54b6df2f44c5cb4f9573f99330c2d2908f1bf506

-Jaikiran


On 11/09/18 12:17 PM, Gintautas Grigelionis wrote:
> How was this different from PR #66?
>
> Gintas
>
> On Tue, 11 Sep 2018 at 06:55, Jaikiran Pai  wrote:
>
>> Things haven't changed (nor do I expect any changes anymore). To say the
>> least - it's followed the same pattern:
>>
>> - do changes like these
>>
>> - when requested not to do such changes, argue over it and move it to
>> some abstract discussion
>>
>> - then give an impression it won't be repeated
>>
>> - few days down the line push changes like these and repeat the whole
>> cycle again.
>>
>> Although I stay silent with these commits these days it's because I have
>> nothing good or new to say about this behaviour and am fully exhausted
>> with this exercise to the extent that I just delete such commit
>> notifications instead of reviewing them, to avoid it ruining any energy
>> I might have to contribute anything in my spare time.
>>
>> Committer rights is a privilege as well as a responsibility, but this
>> behaviour is nothing but an abuse of it and no different than being a
>> troll.
>>
>> -Jaikiran
>>
>>
>> On 10/09/18 5:12 AM, Nicolas Lalevée wrote:
>>> I have been away from the project out of boredom. Still curious, I came
>> to read some emails. It seems things didn’t changed much: yet another
>> unreadable commit with a log which doesn’t indicate what it actually do.
>>>
>>>> Le 9 sept. 2018 à 09:09, gin...@apache.org a écrit :
>>>>
>>>> Repository: ant
>>>> Updated Branches:
>>>>  refs/heads/master fde6b0e94 -> 54b6df2f4
>>>>
>>>>
>>>> Check spelling
>>>>
>>>> Project: http://git-wip-us.apache.org/repos/asf/ant/repo
>>>> Commit: http://git-wip-us.apache.org/repos/asf/ant/commit/54b6df2f
>>>> Tree: http://git-wip-us.apache.org/repos/asf/ant/tree/54b6df2f
>>>> Diff: http://git-wip-us.apache.org/repos/asf/ant/diff/54b6df2f
>>>>
>>>> Branch: refs/heads/master
>>>> Commit: 54b6df2f44c5cb4f9573f99330c2d2908f1bf506
>>>> Parents: fde6b0e
>>>> Author: Gintas Grigelionis 
>>>> Authored: Sat Sep 8 22:12:24 2018 +0200
>>>> Committer: Gintas Grigelionis 
>>>> Committed: Sun Sep 9 09:07:18 2018 +0200
>>>>
>>>> --
>>>> .../checkstyle-frames-sortby-check.xsl  | 194
>> +--
>>>> src/etc/jdepend-frames.xsl  |  18 +-
>>>> src/etc/jdepend.xsl |  48 +++--
>>>> src/etc/testcases/taskdefs/exec/exec.xml|   4 +-
>>>> .../taskdefs/optional/unix/symlink.xml  |  78 
>>>> .../optional/xml/endpiece-noSchema-invalid.xml  |   9 +-
>>>> .../taskdefs/optional/xml/endpiece-noSchema.xml |   7 +-
>>>> src/etc/testcases/types/assertions.xml  | 178 +
>>>> src/etc/testcases/types/selectors.xml   | 104 +-
>>>> src/main/org/apache/tools/ant/Diagnostics.java  |   2 +-
>>>> src/main/org/apache/tools/ant/taskdefs/Ant.java |   2 +-
>>>> .../org/apache/tools/ant/taskdefs/Checksum.java |   2 +-
>>>> .../org/apache/tools/ant/taskdefs/Exec.java |   2 +-
>>>> .../org/apache/tools/ant/taskdefs/SignJar.java  |   2 +-
>>>> src/main/org/apache/tools/ant/taskdefs/Zip.java |   2 +-
>>>> .../ant/taskdefs/condition/IsReachable.java |   4 +-
>>>> .../optional/ejb/GenericDeploymentTool.java |   4 +-
>>>> .../optional/ejb/JonasDeploymentTool.java   |   4 +-
>>>> .../tools/ant/taskdefs/optional/jsp/WLJspc.java |   2 +-
>>>> .../junitlauncher/JUnitLauncherTask.java|   2 +-
>>>> .../optional/junitlauncher/TestRequest.java |   8 +-
>>>> .../tools/ant/taskdefs/optional/net/FT

Re: ant git commit: Check spelling

2018-09-10 Thread Jaikiran Pai
Things haven't changed (nor do I expect any changes anymore). To say the
least - it's followed the same pattern:

- do changes like these

- when requested not to do such changes, argue over it and move it to
some abstract discussion

- then give an impression it won't be repeated

- few days down the line push changes like these and repeat the whole
cycle again.

Although I stay silent with these commits these days it's because I have
nothing good or new to say about this behaviour and am fully exhausted
with this exercise to the extent that I just delete such commit
notifications instead of reviewing them, to avoid it ruining any energy
I might have to contribute anything in my spare time.

Committer rights is a privilege as well as a responsibility, but this
behaviour is nothing but an abuse of it and no different than being a troll.

-Jaikiran


On 10/09/18 5:12 AM, Nicolas Lalevée wrote:
> I have been away from the project out of boredom. Still curious, I came to 
> read some emails. It seems things didn’t changed much: yet another unreadable 
> commit with a log which doesn’t indicate what it actually do.
>
>
>> Le 9 sept. 2018 à 09:09, gin...@apache.org a écrit :
>>
>> Repository: ant
>> Updated Branches:
>>  refs/heads/master fde6b0e94 -> 54b6df2f4
>>
>>
>> Check spelling
>>
>> Project: http://git-wip-us.apache.org/repos/asf/ant/repo
>> Commit: http://git-wip-us.apache.org/repos/asf/ant/commit/54b6df2f
>> Tree: http://git-wip-us.apache.org/repos/asf/ant/tree/54b6df2f
>> Diff: http://git-wip-us.apache.org/repos/asf/ant/diff/54b6df2f
>>
>> Branch: refs/heads/master
>> Commit: 54b6df2f44c5cb4f9573f99330c2d2908f1bf506
>> Parents: fde6b0e
>> Author: Gintas Grigelionis 
>> Authored: Sat Sep 8 22:12:24 2018 +0200
>> Committer: Gintas Grigelionis 
>> Committed: Sun Sep 9 09:07:18 2018 +0200
>>
>> --
>> .../checkstyle-frames-sortby-check.xsl  | 194 +--
>> src/etc/jdepend-frames.xsl  |  18 +-
>> src/etc/jdepend.xsl |  48 +++--
>> src/etc/testcases/taskdefs/exec/exec.xml|   4 +-
>> .../taskdefs/optional/unix/symlink.xml  |  78 
>> .../optional/xml/endpiece-noSchema-invalid.xml  |   9 +-
>> .../taskdefs/optional/xml/endpiece-noSchema.xml |   7 +-
>> src/etc/testcases/types/assertions.xml  | 178 +
>> src/etc/testcases/types/selectors.xml   | 104 +-
>> src/main/org/apache/tools/ant/Diagnostics.java  |   2 +-
>> src/main/org/apache/tools/ant/taskdefs/Ant.java |   2 +-
>> .../org/apache/tools/ant/taskdefs/Checksum.java |   2 +-
>> .../org/apache/tools/ant/taskdefs/Exec.java |   2 +-
>> .../org/apache/tools/ant/taskdefs/SignJar.java  |   2 +-
>> src/main/org/apache/tools/ant/taskdefs/Zip.java |   2 +-
>> .../ant/taskdefs/condition/IsReachable.java |   4 +-
>> .../optional/ejb/GenericDeploymentTool.java |   4 +-
>> .../optional/ejb/JonasDeploymentTool.java   |   4 +-
>> .../tools/ant/taskdefs/optional/jsp/WLJspc.java |   2 +-
>> .../junitlauncher/JUnitLauncherTask.java|   2 +-
>> .../optional/junitlauncher/TestRequest.java |   8 +-
>> .../tools/ant/taskdefs/optional/net/FTP.java|   4 +-
>> .../optional/net/FTPTaskMirrorImpl.java |   4 +-
>> .../tools/ant/taskdefs/optional/vss/MSVSS.java  |   2 +-
>> .../ant/taskdefs/optional/vss/MSVSSCHECKIN.java |   2 +-
>> .../org/apache/tools/ant/types/XMLCatalog.java  |   2 +-
>> .../org/apache/tools/ant/util/FileUtils.java|   2 +-
>> .../org/apache/tools/ant/util/ProxySetup.java   |   2 +-
>> .../org/apache/tools/zip/ZipOutputStream.java   |   4 +-
>> src/script/antenv.cmd   |   2 +-
>> src/script/envset.cmd   |   2 +-
>> src/tests/antunit/taskdefs/echoxml-test.xml |   2 +-
>> .../apache/tools/ant/taskdefs/UnzipTest.java|   2 +-
>> .../ant/taskdefs/optional/TraXLiaisonTest.java  |   2 +-
>> .../tools/ant/util/ReaderInputStreamTest.java   |   4 +-
>> 35 files changed, 350 insertions(+), 362 deletions(-)
>> --
>>
>>
>> http://git-wip-us.apache.org/repos/asf/ant/blob/54b6df2f/src/etc/checkstyle/checkstyle-frames-sortby-check.xsl
>> --
>> diff --git a/src/etc/checkstyle/checkstyle-frames-sortby-check.xsl 
>> b/src/etc/checkstyle/checkstyle-frames-sortby-check.xsl
>> index 060f878..1f02b90 100644

Re: ant-ivy git commit: Update the release notes

2018-09-10 Thread Jaikiran Pai
Hi Maarten,

Agreed - the change(s) should be done taking into account any existing
caches (from previous version of Ivy). As of now, I have reverted my
changes which had introduced the test failures. To fix properly, it will
require a couple of hours of dedicated work to make sure all cases are
covered. However, I haven't been able to focus on it at a stretch and
would like to finish off some pending junitlauncher task work in Ant
project, before I can get to this. Hence I decided to undo my changes
for now and leave it in a state as of our latest released version.

-Jaikiran


On 29/08/18 8:27 PM, Maarten Coene wrote:
> Without knowing the details of the change, one thing we should take care 
> about is that older Ivy versions should still be able to read that property 
> properly.
> Maarten
>
>Op woensdag 29 augustus 2018 16:48:01 CEST schreef Gintautas Grigelionis 
> :  
>  
>  I like the idea, though. One thing that should be investigated further is
> places where location is obtained by getResource().getName()
> AFAICS that happens in CacheResolver (deprecated), BasicResolver (where
> also a Resource is constructed from location), and
> DefaultRepositoryCacheManager. There's no uniformity in
> Resource-implementing classes either, sometimes getName() works on an URI,
> sometimes a path string.
>
> Gintas
>
> On Wed, 29 Aug 2018 at 08:34, Jaikiran Pai  wrote:
>
>> More of a FYI - I'm still not convinced that my fix for this handles all
>> the necessary cases (looks like the ArtifactOrigin#location gets used in
>> various different ways), so I may either revert back my changes or
>> decide to change it in a different way. So right now, in its current
>> form, my changes aren't a fix.
>>
>> -Jaikiran
>>
>>
>> On 29/08/18 11:34 AM, gin...@apache.org wrote:
>>> Repository: ant-ivy
>>> Updated Branches:
>>>   refs/heads/master d976a4a27 -> fd81f4461
>>>
>>>
>>> Update the release notes
>>>
>>> Project: http://git-wip-us.apache.org/repos/asf/ant-ivy/repo
>>> Commit: http://git-wip-us.apache.org/repos/asf/ant-ivy/commit/fd81f446
>>> Tree: http://git-wip-us.apache.org/repos/asf/ant-ivy/tree/fd81f446
>>> Diff: http://git-wip-us.apache.org/repos/asf/ant-ivy/diff/fd81f446
>>>
>>> Branch: refs/heads/master
>>> Commit: fd81f44619b05a176ecbf4ff1499d64b39251520
>>> Parents: d976a4a
>>> Author: Gintas Grigelionis 
>>> Authored: Wed Aug 29 08:03:13 2018 +0200
>>> Committer: Gintas Grigelionis 
>>> Committed: Wed Aug 29 08:05:12 2018 +0200
>>>
>>> --
>>>   asciidoc/release-notes.adoc | 3 ++-
>>>   1 file changed, 2 insertions(+), 1 deletion(-)
>>> --
>>>
>>>
>>>
>> http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/fd81f446/asciidoc/release-notes.adoc
>>> --
>>> diff --git a/asciidoc/release-notes.adoc b/asciidoc/release-notes.adoc
>>> index cc53bb3..efa7057 100644
>>> --- a/asciidoc/release-notes.adoc
>>> +++ b/asciidoc/release-notes.adoc
>>> @@ -85,6 +85,7 @@ For details about the following changes, check our
>> JIRA install at link:https://
>>>   - FIX: Don't throw a CircularDependencyException when parsing an import
>> scoped dependency in dependencyManagement section of a pom (jira:IVY-1588[])
>>>   - FIX: Respect exclude regardless of resolution order (jira:IVY-1486[])
>> (thanks to David Turner)
>>>   - FIX: ModuleDescriptorMemoryCache didn't detect outdated entries when
>> Ivy file was updated in the cache by another process
>>> +- FIX: Store ArtifactOrigin's location as a URL
>>>
>>>   - IMPROVEMENT: Throw an IllegalStateException when retrieving the
>> resolutionCacheRoot on the DefaultResolutionCacheManager if the basedir (or
>> IvySettings) is not set (jira:IVY-1482[])
>>>   - IMPROVEMENT: Optimization: limit the revision numbers scanned if
>> revision prefix is specified (Thanks to Ernestas Vaiciukeviius)
>>> @@ -181,7 +182,6 @@ Here is the list of people who have contributed
>> source code and documentation up
>>>   * Tobias Himstedt
>>>   * Achim Huegen
>>>   * Pierre Hgnestrand
>>> -* Ilya
>>>   * Matt Inger
>>>   * Anders Jacobsson
>>>   * Anders Janmyr
>>> @@ -196,6 +196,7 @@ Here is the list of people who have contributed
>> source code and documentation up
>>>   * Sebastian Krueger
>>>   * Thomas Kurpick
>>>   * Costin Leau
>>> +* Ilya Leoshkevich
>>>   * Tat Leung
>>>   * Antoine Levy-Lambert
>>>   * Tony Likhite
>>>
>>
>> -
>> 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: JDK 12 & JMC 7.0.0 Early Access builds are available

2018-09-09 Thread Jaikiran Pai
Hi Rory,


On 07/09/18 2:58 PM, Rory O'Donnell wrote:
>
>
> Can you confirm the fix in JDK 12 b09, thanks ?
>
>
> *FOSS bug fixes in recent builds.*
>
>  * *Apache Ant -
>    **JDK-8209965<https://bugs.openjdk.java.net/browse/JDK-8209965>**(b09)*

I gave the JDK 12 EA version a try:

java -version
openjdk version "12-ea" 2019-03-19
OpenJDK Runtime Environment 19.3 (build 12-ea+10)
OpenJDK 64-Bit Server VM 19.3 (build 12-ea+10, mixed mode)

and can confirm that this issue is indeed fixed in that version.

-Jaikiran

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



Re: new release

2018-09-05 Thread Jaikiran Pai
Hi Simon,

Is there a specific issue that you want to be part of the release?

-Jaikiran


On 06/09/18 2:20 AM, Simon IJskes - QCG wrote:
> Hi,
>
> Is it possible to cast a new release? If possible within 2 weeks?
>
> https://cwiki.apache.org/confluence/display/NETBEANS/Apache+NetBeans+Release+Roadmap
>
>
> states a feature freeze at 24 september, and it would be nice to have
> the latest fixes included in the netbeans release.
>
> Anything i can do?
>
> Gr. 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-ivy git commit: Update the release notes

2018-08-29 Thread Jaikiran Pai
More of a FYI - I'm still not convinced that my fix for this handles all
the necessary cases (looks like the ArtifactOrigin#location gets used in
various different ways), so I may either revert back my changes or
decide to change it in a different way. So right now, in its current
form, my changes aren't a fix.

-Jaikiran


On 29/08/18 11:34 AM, gin...@apache.org wrote:
> Repository: ant-ivy
> Updated Branches:
>   refs/heads/master d976a4a27 -> fd81f4461
>
>
> Update the release notes
>
> Project: http://git-wip-us.apache.org/repos/asf/ant-ivy/repo
> Commit: http://git-wip-us.apache.org/repos/asf/ant-ivy/commit/fd81f446
> Tree: http://git-wip-us.apache.org/repos/asf/ant-ivy/tree/fd81f446
> Diff: http://git-wip-us.apache.org/repos/asf/ant-ivy/diff/fd81f446
>
> Branch: refs/heads/master
> Commit: fd81f44619b05a176ecbf4ff1499d64b39251520
> Parents: d976a4a
> Author: Gintas Grigelionis 
> Authored: Wed Aug 29 08:03:13 2018 +0200
> Committer: Gintas Grigelionis 
> Committed: Wed Aug 29 08:05:12 2018 +0200
>
> --
>  asciidoc/release-notes.adoc | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> --
>
>
> http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/fd81f446/asciidoc/release-notes.adoc
> --
> diff --git a/asciidoc/release-notes.adoc b/asciidoc/release-notes.adoc
> index cc53bb3..efa7057 100644
> --- a/asciidoc/release-notes.adoc
> +++ b/asciidoc/release-notes.adoc
> @@ -85,6 +85,7 @@ For details about the following changes, check our JIRA 
> install at link:https://
>  - FIX: Don't throw a CircularDependencyException when parsing an import 
> scoped dependency in dependencyManagement section of a pom (jira:IVY-1588[])
>  - FIX: Respect exclude regardless of resolution order (jira:IVY-1486[]) 
> (thanks to David Turner)
>  - FIX: ModuleDescriptorMemoryCache didn't detect outdated entries when Ivy 
> file was updated in the cache by another process
> +- FIX: Store ArtifactOrigin's location as a URL
>  
>  - IMPROVEMENT: Throw an IllegalStateException when retrieving the 
> resolutionCacheRoot on the DefaultResolutionCacheManager if the basedir (or 
> IvySettings) is not set (jira:IVY-1482[])
>  - IMPROVEMENT: Optimization: limit the revision numbers scanned if revision 
> prefix is specified (Thanks to Ernestas Vaiciukeviius)
> @@ -181,7 +182,6 @@ Here is the list of people who have contributed source 
> code and documentation up
>  * Tobias Himstedt
>  * Achim Huegen
>  * Pierre Hgnestrand
> -* Ilya
>  * Matt Inger
>  * Anders Jacobsson
>  * Anders Janmyr
> @@ -196,6 +196,7 @@ Here is the list of people who have contributed source 
> code and documentation up
>  * Sebastian Krueger
>  * Thomas Kurpick
>  * Costin Leau
> +* Ilya Leoshkevich
>  * Tat Leung
>  * Antoine Levy-Lambert
>  * Tony Likhite
>


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



Re: JDK 11: First Release Candidate available

2018-08-27 Thread Jaikiran Pai
Hi Rory,

Except for one issue[1] in this release candidate build, so far the
tests against this version have gone fine. A fix/patch has already been
provided for that issue and it works fine. I plan to run some more
extensive tests over the next few days against this version.

[1] https://bugs.openjdk.java.net/browse/JDK-8209965

-Jaikiran


On 24/08/18 2:35 PM, Rory O'Donnell wrote:
> Hi Stefan,
>
> *JDK 11 build 28 is our first JDK 11 Release Candidate [1]
> *
>
>  * JDK 11 Early Access  build 28 is available at : - jdk.java.net/11/
>
> *FOSS fixes in recent builds.*
>
>  * Eclipse Jetty - JDK-8207177
>    <https://bugs.openjdk.java.net/browse/JDK-8207177> (b27)
>  * Apache Tomcat   -JDK-8208642
>    <https://bugs.openjdk.java.net/browse/JDK-8208642>(b27)
>  * JBoss Netty - JDK-8207029
>    <https://bugs.openjdk.java.net/browse/JDK-8207029> (b23),
>    JDK-8208166 <https://bugs.openjdk.java.net/browse/JDK-8208166> (b25)
>
> *JDK 12 Early Access build 8 is available at : - jdk.java.net/12/*
>
>  * Release Notes for JDK 12 [2]
>  * Changes in this build include
>  o JDK-8208350 <https://bugs.openjdk.java.net/browse/JDK-8208350> -
>    Disable all DES TLS cipher suites
>
> *OpenJFX Early-Access Build 24 is available at :-*
> *http://jdk.java.net/openjfx/*
>
>  * This library is delivered as a set of modules, along with the native
>    code needed to run JavaFX, that can be run using a JDK 10
>    <http://jdk.java.net/10/> build or a JDK 11 EA
>    <http://jdk.java.net/11/> build.
>  * This build is intended to allow application developers and OpenJFX
>    contributors to test their applications with an unbundled,
>    standalone JavaFX library.
>
> Regards,
> Rory
>
> [1]
> http://mail.openjdk.java.net/pipermail/jdk-dev/2018-August/001844.html
> <http://openjdk.java.net/projects/jdk/11/#Schedule>
> [2] http://jdk.java.net/12/release-notes
>
>



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



Re: Build failed in Jenkins: Ant-Build-Matrix-master-Windows » JDK 10 b46 (Windows Only),Windows #771

2018-08-27 Thread Jaikiran Pai
I am going to disable this JDK 10 b46 against Windows job. It's been
failing for a while and all due to infrastructure issues. I don't see
any other JDK 10 (Windows) selection option either. Any objections to
disabling these tests against this version, on Windows?

-Jaikiran

On 27/08/18 5:59 PM, Apache Jenkins Server wrote:
> See 
> <https://builds.apache.org/job/Ant-Build-Matrix-master-Windows/jdk=JDK%2010%20b46%20(Windows%20Only),label_exp=Windows/771/display/redirect>
>
> --
> Started by upstream project "Ant-Build-Matrix-master-Windows" build number 771
> originally caused by:
>  Started by an SCM change
> [EnvInject] - Loading node environment variables.
> Building remotely on windows-2016-1 (Windows) in workspace 
> <https://builds.apache.org/job/Ant-Build-Matrix-master-Windows/jdk=JDK%2010%20b46%20(Windows%20Only),label_exp=Windows/ws/>
> [WS-CLEANUP] Deleting project workspace...
> ERROR: [WS-CLEANUP] Cannot delete workspace: remote file operation failed: 
> <https://builds.apache.org/job/Ant-Build-Matrix-master-Windows/jdk=JDK%2010%20b46%20(Windows%20Only),label_exp=Windows/ws/>
>  at hudson.remoting.Channel@1c74f1c0:JNLP4-connect connection from 
> ec2-34-228-168-168.compute-1.amazonaws.com/34.228.168.168:57603: 
> java.nio.file.AccessDeniedException: 
> <https://builds.apache.org/job/Ant-Build-Matrix-master-Windows/jdk=JDK%2010%20b46%20(Windows%20Only),label_exp=Windows/ws/>
>  -> 
> <https://builds.apache.org/job/Ant-Build-Matrix-master-Windows/jdk=JDK%2010%20b46%20(Windows%20Only),label_exp=Windows/ws/_ws-cleanup_1535372992775>
> ERROR: Cannot delete workspace: remote file operation failed: 
> <https://builds.apache.org/job/Ant-Build-Matrix-master-Windows/jdk=JDK%2010%20b46%20(Windows%20Only),label_exp=Windows/ws/>
>  at hudson.remoting.Channel@1c74f1c0:JNLP4-connect connection from 
> ec2-34-228-168-168.compute-1.amazonaws.com/34.228.168.168:57603: 
> java.nio.file.AccessDeniedException: 
> <https://builds.apache.org/job/Ant-Build-Matrix-master-Windows/jdk=JDK%2010%20b46%20(Windows%20Only),label_exp=Windows/ws/>
>  -> 
> <https://builds.apache.org/job/Ant-Build-Matrix-master-Windows/jdk=JDK%2010%20b46%20(Windows%20Only),label_exp=Windows/ws/_ws-cleanup_1535372992775>
> Recording test results
> ERROR: Step ‘Publish JUnit test result report’ failed: Test reports were 
> found but none of them are new. Did leafNodes run? 
> For example, 
> <https://builds.apache.org/job/Ant-Build-Matrix-master-Windows/jdk=JDK%2010%20b46%20(Windows%20Only),label_exp=Windows/ws/build\antunit\xml\TEST-src.tests.antunit.bugfixes.br50866.br50866-test_xml.xml>
>  is 1 mo 12 days old
>


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



[GitHub] ant pull request #68: bz-62655 throw a BuildException from augment task

2018-08-25 Thread jaikiran
GitHub user jaikiran opened a pull request:

https://github.com/apache/ant/pull/68

bz-62655 throw a BuildException from augment task 

Reference https://bz.apache.org/bugzilla/show_bug.cgi?id=62655

The manual of the augment task[1] states that it's supposed to throw a 
`BuildException` if the referenced id value isn't known. I admit that the 
bugzilla is more about the id attribute not being specified whereas the manual 
seems to talk about the value of id being unknown reference, but I think the 
issue itself can be considered valid.

The referenced bugzilla issue shows that it throws an 
`IllegalStateException`. That exception then does indeed get thrown as a 
BuildException[2] but the `reason` that gets reported to the build listeners[3] 
is the original cause (in this case the `IllegalStateException`).

The commit here is trivial and it throws the `BuildException` from the 
`augment` task when either `id` isn't specified or it points to an unknown 
reference. However, given that it appears that this task has always been in 
this manner, I wanted to make sure there isn't any specific reason of its 
current implementation.

There's already tests for this task which pass both with and without this 
change[4]


[1] https://ant.apache.org/manual/Tasks/augment.html
[2] 
https://github.com/apache/ant/blob/1.9.x/src/main/org/apache/tools/ant/Task.java#L360
[3] 
https://github.com/apache/ant/blob/1.9.x/src/main/org/apache/tools/ant/Task.java#L368
[4] 
https://github.com/apache/ant/blob/1.9.x/src/tests/antunit/taskdefs/augment-test.xml

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/jaikiran/ant bz-62655-19x

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ant/pull/68.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #68


commit 21de7add9a935c4ae61716cce269f58db26e949a
Author: Jaikiran Pai 
Date:   2018-08-25T11:43:31Z

bz-62655 throw a BuildException from augment task if the id attribute isn't 
specified or if the value points to an unknown reference




---

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



Re: Build failed in Jenkins: Ivy-tests-ubuntu » ubuntu,JDK 1.7 (latest) #360

2018-08-24 Thread Jaikiran Pai
More of a FYI - The URLResolverTest failures, in this list, appear to be
my fault, introduced in a commit I pushed this week. I will take a look
tonight to see what the issue there is and fix (or rollback) my changes.

-Jaikiran


On 24/08/18 12:22 PM, Apache Jenkins Server wrote:
> See 
> <https://builds.apache.org/job/Ivy-tests-ubuntu/OS=ubuntu,jdk=JDK%201.7%20(latest)/360/display/redirect?page=changes>
>
> Changes:
>
> [maartenc] FIX: ModuleDescriptorMemoryCache didn't detect outdated entries 
> when Ivy
>
> --
> [...truncated 32.16 KB...]
> [junit] Tests run: 13, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
> 2,962 sec
> [junit] Running org.apache.ivy.ant.IvyCleanCacheTest
> [junit] Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
> 1,552 sec
> [junit] Running org.apache.ivy.ant.IvyConfigureTest
> [junit] Tests run: 14, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
> 1,596 sec
> [junit] Running org.apache.ivy.ant.IvyConvertPomTest
> [junit] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
> 1,937 sec
> [junit] Running org.apache.ivy.ant.IvyDeliverTest
> [junit] Tests run: 15, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
> 4,205 sec
> [junit] Running org.apache.ivy.ant.IvyDependencyTreeTest
> [junit] Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
> 2,566 sec
> [junit] Running org.apache.ivy.ant.IvyDependencyUpdateCheckerTest
> [junit] Tests run: 14, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
> 2,926 sec
> [junit] Running org.apache.ivy.ant.IvyFindRevisionTest
> [junit] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
> 1,868 sec
> [junit] Running org.apache.ivy.ant.IvyInfoRepositoryTest
> [junit] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
> 1,778 sec
> [junit] Running org.apache.ivy.ant.IvyInfoTest
> [junit] Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
> 1,749 sec
> [junit] Running org.apache.ivy.ant.IvyInstallTest
> [junit] Tests run: 15, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
> 3,384 sec
> [junit] Running org.apache.ivy.ant.IvyListModulesTest
> [junit] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
> 1,618 sec
> [junit] Running org.apache.ivy.ant.IvyPostResolveTaskTest
> [junit] Tests run: 13, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
> 2,92 sec
> [junit] Running org.apache.ivy.ant.IvyPublishTest
> [junit] Tests run: 22, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
> 4,851 sec
> [junit] Running org.apache.ivy.ant.IvyReportTest
> [junit] Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
> 3,306 sec
> [junit] Running org.apache.ivy.ant.IvyRepositoryReportTest
> [junit] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
> 2,284 sec
> [junit] Running org.apache.ivy.ant.IvyResolveTest
> [junit] Tests run: 35, Failures: 0, Errors: 0, Skipped: 1, Time elapsed: 
> 4,11 sec
> [junit] Running org.apache.ivy.ant.IvyResourcesTest
> [junit] Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
> 2,492 sec
> [junit] Running org.apache.ivy.ant.IvyRetrieveBuildFileTest
> [junit] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
> 2,295 sec
> [junit] Running org.apache.ivy.ant.IvyRetrieveTest
> [junit] Tests run: 19, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
> 3,52 sec
> [junit] Running org.apache.ivy.ant.IvyTaskTest
> [junit] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
> 1,524 sec
> [junit] Running org.apache.ivy.ant.IvyVarTest
> [junit] Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
> 1,602 sec
> [junit] Running org.apache.ivy.core.NormalRelativeUrlResolverTest
> [junit] Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
> 0,324 sec
> [junit] Running 
> org.apache.ivy.core.cache.DefaultRepositoryCacheManagerTest
> [junit] Tests run: 4, Failures: 0, Errors: 0, Skipped: 1, Time elapsed: 
> 1,011 sec
> [junit] Running org.apache.ivy.core.cache.ModuleDescriptorMemoryCacheTest
> [junit] Tests run: 10, Failures: 0, Errors: 4, Skipped: 0, Time elapsed: 
> 1,004 sec
> [junit] Test org.apache.ivy.core.cache.ModuleDescriptorMemoryCacheTest 
> FAILED
> [junit] Running org.apache.ivy.core.deliver.DeliverTest
> [junit] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
> 2,105 sec
> [junit] Running org.apache.ivy.core.event.IvyEventFilterTest
> [junit] Tests run: 5, Failures: 0, Errors: 0, Skip

Re: junitlauncher task - support for system properties in a non-forked execution

2018-08-21 Thread Jaikiran Pai
Hi Stefan,


On 22/08/18 12:00 AM, Stefan Bodewig wrote:
> On 2018-08-16, Jaikiran Pai wrote:
>
>> However, I would like some inputs on whether such support for setting
>> the system properties in a non-forked execution should be at the
>> junitlauncher task level or whether it should be configured within
>> each  and  level. Or should we allow it to
>> configured at the task level as well as the individual
>> / level?
>> junit task currently does it only at the task level.
> If you really need to have different env variables for different tests
> then I think the effort of configuring this properly isn't much less
> than having to configure two instances of the junitlaucher task. IMHO
> setting them at the task level should be enough, at least until anybody
> makes a good case for more granular control.

That's a good point. I think that will also make the implementation of
this task much simpler.

I won't add the sysproperty support for non-forked mode now and let
users try it out in the forked mode. As you note, only if there's some
real usecase/request for supporting this in non-forked mode, I will
revisit the feature. Thank you for your inputs.

-Jaikiran


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



tstamp testMagicProperty consistently failing on Windows

2018-08-19 Thread Jaikiran Pai
The tstamp (antunit) test named "testMagicProperty" has been
consistently failing (only) on Windows for a while now[1]. Both master
and 1.9.x branches. The failure looks really odd and something that I
haven't been able to understand yet. The one interesting bit to this
failure, based on what I can find in the history, is that it fails only
on "windows-2016" node(s) but has passed (and still passes) on
"windows-2012" node(s).

Looking at the tstamp task code, I haven't yet found out what can lead
to this issue. The only way I can think of this happening is that the
number of seconds being added to the epoch is less than a day's value -
which isn't the case in that test case which adds 10 seconds.


https://builds.apache.org/job/Ant-Build-Matrix-master-Windows/jdk=JDK%201.8.0_121%20(unlimited%20security)%2064-bit%20Windows%20only,label_exp=Windows/lastCompletedBuild/testReport/src.tests.antunit.taskdefs/tstamp-test_xml/testMagicProperty/

-Jaikiran



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



junitlauncher task - support for system properties in a non-forked execution

2018-08-16 Thread Jaikiran Pai
While working on the documentation of the junitlauncher task, for fork
support, I realized that when we first released this task, due to an
oversight, I did not add support for setting system properties or
environment variables through this task. The fork element now supports
that[1] in the upcoming release, so that the forked JVM can be
configured with system properties and/or environment variables.

I am thinking of adding this support for even non-forked execution, like
junit task does. However, I would like some inputs on whether such
support for setting the system properties in a non-forked execution
should be at the junitlauncher task level or whether it should be
configured within each  and  level. Or should we
allow it to configured at the task level as well as the individual
/ level?

junit task currently does it only at the task level.

[1]
https://github.com/apache/ant/commit/ffb80b688a12d4e60ab4be466ec0b3e396bb0078

-Jaikiran



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



Re: ant git commit: Use try-with-resources and ExpectedException

2018-08-15 Thread Jaikiran Pai
Is that the reason you moved to this style of coding? I don't plan to
use ExpectedException or that style of testing in code that I write. Are
you going to keep overriding such commits?

-Jaikiran

On 15/08/18 1:18 PM, Gintautas Grigelionis wrote:
> Jaikiran,
>
> your code allowed for false positives, too
>
> Gintas
>
> On Wed, 15 Aug 2018 at 09:11, Gintautas Grigelionis 
> wrote:
>
>> I believe we discussed writing tests before. It is not a matter of style,
>> but of keeping assumptions and assertions explicit.
>> You replaced a JUnit 4 assertion with some code that works, but is far
>> from being clear.
>> There is a reason why JUnit provides specialised assert... methods and you
>> could have at least used assertEquals()
>> on exception message rather than rethrowing it. That would have been
>> helpful in eventual migration to JUnit 5, too.
>>
>> Gintas
>>
>> On Wed, 15 Aug 2018 at 03:14, Jaikiran Pai  wrote:
>>
>>> Gintas,
>>>
>>>
>>> On 14/08/18 10:14 PM, gin...@apache.org wrote:
>>> http://git-wip-us.apache.org/repos/asf/ant/blob/e648224f/src/tests/junit/org/apache/tools/ant/taskdefs/email/EmailTaskTest.java
>>>> --
>>>> diff --git
>>> a/src/tests/junit/org/apache/tools/ant/taskdefs/email/EmailTaskTest.java
>>> b/src/tests/junit/org/apache/tools/ant/taskdefs/email/EmailTaskTest.java
>>>> index a77fc92..0d0c36a 100644
>>>> ---
>>> a/src/tests/junit/org/apache/tools/ant/taskdefs/email/EmailTaskTest.java
>>>> +++
>>> b/src/tests/junit/org/apache/tools/ant/taskdefs/email/EmailTaskTest.java
>>>> @@ -25,6 +25,7 @@ import org.junit.Assert;
>>>>  import org.junit.Before;
>>>>  import org.junit.Rule;
>>>>  import org.junit.Test;
>>>> +import org.junit.rules.ExpectedException;
>>>>
>>>>  /**
>>>>   * TODO : develop these testcases - the email task needs to have
>>> attributes allowing
>>>> @@ -35,6 +36,9 @@ public class EmailTaskTest {
>>>>  @Rule
>>>>  public BuildFileRule buildRule = new BuildFileRule();
>>>>
>>>> +@Rule
>>>> +public ExpectedException thrown = ExpectedException.none();
>>>> +
>>>>  @Before
>>>>  public void setUp() {
>>>>
>>> buildRule.configureProject("src/etc/testcases/taskdefs/email/mail.xml");
>>>> @@ -45,14 +49,9 @@ public class EmailTaskTest {
>>>>   */
>>>>  @Test
>>>>  public void test1() {
>>>> -try {
>>>> -buildRule.executeTarget("test1");
>>>> -} catch (BuildException e) {
>>>> -// assert it's the expected one
>>>> -if (!e.getMessage().equals("SMTP auth only possible with
>>> MIME mail")) {
>>>> -throw e;
>>>> -}
>>>> -}
>>>> +thrown.expect(BuildException.class);
>>>> +thrown.expectMessage("SMTP auth only possible with MIME mail");
>>>> +buildRule.executeTarget("test1");
>>>>  }
>>>>
>>>>  /**
>>>> @@ -60,14 +59,9 @@ public class EmailTaskTest {
>>>>   */
>>>>  @Test
>>>>  public void test2() {
>>>> -try {
>>>> -buildRule.executeTarget("test2");
>>>> -} catch (BuildException e) {
>>>> -// assert it's the expected one
>>>> -if (!e.getMessage().equals("SSL and STARTTLS only possible
>>> with MIME mail")) {
>>>> -throw e;
>>>> -}
>>>> -}
>>>> +thrown.expect(BuildException.class);
>>>> +thrown.expectMessage("SSL and STARTTLS only possible with MIME
>>> mail");
>>>> +buildRule.executeTarget("test2");
>>>>  }
>>>>
>>>>  /**
>>> Could you tell me what was technically wrong with the way I had
>>> committed it yesterday and why you felt that it had to be changed into
>>> this form?
>>>
>>> When I looked into this test during the last couple of days, I realized
>>> they weren't functional and were broken. So I fixed them and used a
>>> particular coding style that I am comfortable with. I am not a fan of
>>> using the @Rule based expected exceptions which are stored as member
>>> variables in the class and which then have to be setup before the actual
>>> testing happens. To me the try/catch block is much more intuitive and
>>> gives me more control as well as a better read of what the test case
>>> expects. Keeping that detail aside, I decided to use a particular coding
>>> style that I was comfortable with when adding that code. The tests are
>>> working fine. So what was the need to override that commit with a coding
>>> style change? Is this how you are going to continue with your future
>>> commits?
>>>
>>> -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: ant git commit: Use try-with-resources and ExpectedException

2018-08-15 Thread Jaikiran Pai



On 15/08/18 12:41 PM, Gintautas Grigelionis wrote:
> I believe we discussed writing tests before. It is not a matter of style,
> but of keeping assumptions and assertions explicit.
Which assumption are you talking about? Can you use the current commit
to explain it?
> You replaced a JUnit 4 assertion with some code that works, but is far from
> being clear.
Again, can you explain what you mean by that?
> There is a reason why JUnit provides specialised assert... methods and you
> could have at least used assertEquals()
> on exception message rather than rethrowing it.
Like I said, it's my preference how I write it. I don't go around
changing someone else's code just because I don't like their style of
coding. I don't appreciate that being done with mine, when there's no
technical gain achieved with the change.

>  That would have been
> helpful in eventual migration to JUnit 5, too.
JUnit 5 migration isn't related to the commit I am talking about.

-Jaikiran

>
> Gintas
>
> On Wed, 15 Aug 2018 at 03:14, Jaikiran Pai  wrote:
>
>> Gintas,
>>
>>
>> On 14/08/18 10:14 PM, gin...@apache.org wrote:
>> http://git-wip-us.apache.org/repos/asf/ant/blob/e648224f/src/tests/junit/org/apache/tools/ant/taskdefs/email/EmailTaskTest.java
>>> --
>>> diff --git
>> a/src/tests/junit/org/apache/tools/ant/taskdefs/email/EmailTaskTest.java
>> b/src/tests/junit/org/apache/tools/ant/taskdefs/email/EmailTaskTest.java
>>> index a77fc92..0d0c36a 100644
>>> ---
>> a/src/tests/junit/org/apache/tools/ant/taskdefs/email/EmailTaskTest.java
>>> +++
>> b/src/tests/junit/org/apache/tools/ant/taskdefs/email/EmailTaskTest.java
>>> @@ -25,6 +25,7 @@ import org.junit.Assert;
>>>  import org.junit.Before;
>>>  import org.junit.Rule;
>>>  import org.junit.Test;
>>> +import org.junit.rules.ExpectedException;
>>>
>>>  /**
>>>   * TODO : develop these testcases - the email task needs to have
>> attributes allowing
>>> @@ -35,6 +36,9 @@ public class EmailTaskTest {
>>>  @Rule
>>>  public BuildFileRule buildRule = new BuildFileRule();
>>>
>>> +@Rule
>>> +public ExpectedException thrown = ExpectedException.none();
>>> +
>>>  @Before
>>>  public void setUp() {
>>>
>> buildRule.configureProject("src/etc/testcases/taskdefs/email/mail.xml");
>>> @@ -45,14 +49,9 @@ public class EmailTaskTest {
>>>   */
>>>  @Test
>>>  public void test1() {
>>> -try {
>>> -buildRule.executeTarget("test1");
>>> -} catch (BuildException e) {
>>> -// assert it's the expected one
>>> -if (!e.getMessage().equals("SMTP auth only possible with
>> MIME mail")) {
>>> -throw e;
>>> -}
>>> -}
>>> +thrown.expect(BuildException.class);
>>> +thrown.expectMessage("SMTP auth only possible with MIME mail");
>>> +buildRule.executeTarget("test1");
>>>  }
>>>
>>>  /**
>>> @@ -60,14 +59,9 @@ public class EmailTaskTest {
>>>   */
>>>  @Test
>>>  public void test2() {
>>> -try {
>>> -buildRule.executeTarget("test2");
>>> -} catch (BuildException e) {
>>> -// assert it's the expected one
>>> -if (!e.getMessage().equals("SSL and STARTTLS only possible
>> with MIME mail")) {
>>> -throw e;
>>> -}
>>> -}
>>> +thrown.expect(BuildException.class);
>>> +thrown.expectMessage("SSL and STARTTLS only possible with MIME
>> mail");
>>> +buildRule.executeTarget("test2");
>>>  }
>>>
>>>  /**
>> Could you tell me what was technically wrong with the way I had
>> committed it yesterday and why you felt that it had to be changed into
>> this form?
>>
>> When I looked into this test during the last couple of days, I realized
>> they weren't functional and were broken. So I fixed them and used a
>> particular coding style that I am comfortable with. I am not a fan of
>> using the @Rule based expected exceptions which are stored as member
>> variables in the class and which then have to be setup before the actual
>> testing happens. To me the try/catch block is much more intuitive and
>> gives me more control as well as a better read of what the test case
>> expects. Keeping that detail aside, I decided to use a particular coding
>> style that I was comfortable with when adding that code. The tests are
>> working fine. So what was the need to override that commit with a coding
>> style change? Is this how you are going to continue with your future
>> commits?
>>
>> -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: ant git commit: Use try-with-resources and ExpectedException

2018-08-14 Thread Jaikiran Pai
Gintas,


On 14/08/18 10:14 PM, gin...@apache.org wrote:
> http://git-wip-us.apache.org/repos/asf/ant/blob/e648224f/src/tests/junit/org/apache/tools/ant/taskdefs/email/EmailTaskTest.java
> --
> diff --git 
> a/src/tests/junit/org/apache/tools/ant/taskdefs/email/EmailTaskTest.java 
> b/src/tests/junit/org/apache/tools/ant/taskdefs/email/EmailTaskTest.java
> index a77fc92..0d0c36a 100644
> --- a/src/tests/junit/org/apache/tools/ant/taskdefs/email/EmailTaskTest.java
> +++ b/src/tests/junit/org/apache/tools/ant/taskdefs/email/EmailTaskTest.java
> @@ -25,6 +25,7 @@ import org.junit.Assert;
>  import org.junit.Before;
>  import org.junit.Rule;
>  import org.junit.Test;
> +import org.junit.rules.ExpectedException;
>  
>  /**
>   * TODO : develop these testcases - the email task needs to have attributes 
> allowing
> @@ -35,6 +36,9 @@ public class EmailTaskTest {
>  @Rule
>  public BuildFileRule buildRule = new BuildFileRule();
>  
> +@Rule
> +public ExpectedException thrown = ExpectedException.none();
> +
>  @Before
>  public void setUp() {
>  
> buildRule.configureProject("src/etc/testcases/taskdefs/email/mail.xml");
> @@ -45,14 +49,9 @@ public class EmailTaskTest {
>   */
>  @Test
>  public void test1() {
> -try {
> -buildRule.executeTarget("test1");
> -} catch (BuildException e) {
> -// assert it's the expected one
> -if (!e.getMessage().equals("SMTP auth only possible with MIME 
> mail")) {
> -throw e;
> -}
> -}
> +thrown.expect(BuildException.class);
> +thrown.expectMessage("SMTP auth only possible with MIME mail");
> +buildRule.executeTarget("test1");
>  }
>  
>  /**
> @@ -60,14 +59,9 @@ public class EmailTaskTest {
>   */
>  @Test
>  public void test2() {
> -try {
> -buildRule.executeTarget("test2");
> -} catch (BuildException e) {
> -// assert it's the expected one
> -if (!e.getMessage().equals("SSL and STARTTLS only possible with 
> MIME mail")) {
> -throw e;
> -}
> -}
> +thrown.expect(BuildException.class);
> +thrown.expectMessage("SSL and STARTTLS only possible with MIME 
> mail");
> +buildRule.executeTarget("test2");
>  }
>  
>  /**

Could you tell me what was technically wrong with the way I had
committed it yesterday and why you felt that it had to be changed into
this form?

When I looked into this test during the last couple of days, I realized
they weren't functional and were broken. So I fixed them and used a
particular coding style that I am comfortable with. I am not a fan of
using the @Rule based expected exceptions which are stored as member
variables in the class and which then have to be setup before the actual
testing happens. To me the try/catch block is much more intuitive and
gives me more control as well as a better read of what the test case
expects. Keeping that detail aside, I decided to use a particular coding
style that I was comfortable with when adding that code. The tests are
working fine. So what was the need to override that commit with a coding
style change? Is this how you are going to continue with your future
commits?

-Jaikiran



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



Re: mail task

2018-08-13 Thread Jaikiran Pai
Thank you for reporting the issue and testing the fix, Simon.

-Jaikiran


On 14/08/18 1:39 AM, Simon IJskes - QCG wrote:
> fix works. Thanks!
>
> On 08/13/2018 09:55 PM, Simon IJskes - QCG wrote:
>> https://bz.apache.org/bugzilla/show_bug.cgi?id=62621
>>
>> On 08/13/2018 06:07 PM, Jaikiran Pai wrote:
>>> Hi Simon,
>>>
>>> Yes, you can file a bug. I'll update it to record that it's been
>>> handled
>>> in an upcoming release. As usual, our nightly builds are
>>> available[1] to
>>> test this fix, till the release is ready.
>>>
>>> [1]
>>> https://builds.apache.org/job/Ant_Nightly/lastSuccessfulBuild/artifact/
>>>
>>> -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
>


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



Re: mail task

2018-08-13 Thread Jaikiran Pai
Hi Simon,

Yes, you can file a bug. I'll update it to record that it's been handled
in an upcoming release. As usual, our nightly builds are available[1] to
test this fix, till the release is ready.

[1] https://builds.apache.org/job/Ant_Nightly/lastSuccessfulBuild/artifact/

-Jaikiran


On 13/08/18 9:32 PM, Simon IJskes - QCG wrote:
> Thanks,
>
> Shall i still file a bug? I want to give netbeans a heads up when this
> is in a release.
>
> Gr. Simon
>
> On 08/13/2018 04:48 PM, Jaikiran Pai wrote:
>> I pushed a commit to both our 1.9.x and master branches to include a
>> change which should bring in the right jars as part of the fetch.
>>
>> In near future, I'll try and update our mail task tests to be a bit more
>> robust for checking the basic usage of this task.
>>
>> -Jaikiran
>>
>>
>> On 13/08/18 7:17 PM, Jaikiran Pai wrote:
>>> Yes, it looks like one of our changes broke this. We seem to just fetch
>>> the mail API jar(s) and no longer fetch the jars which includethe
>>> provider implementation(s). Can you please file a bug for this, in the
>>> Ant bugzilla?
>>>
>>> -Jaikiran
>>>
>>>
>>> On 13/08/18 7:13 PM, Simon IJskes - QCG wrote:
>>>> It looks like javax.mail-1.6.1.jar is missing.
>>>>
>>>> By manually copying this jar into the lib directory it works.
>>>>
>>>> Before that i've tried to add a dependency in lib/ant-javamail.pom and
>>>> running fetch again but that did not fix it:
>>>>
>>>> 
>>>>  com.sun.mail
>>>>  javax.mail
>>>>  1.6.1
>>>> 
>>>>
>>>>
>
>
> -
> 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: mail task

2018-08-13 Thread Jaikiran Pai
I pushed a commit to both our 1.9.x and master branches to include a
change which should bring in the right jars as part of the fetch.

In near future, I'll try and update our mail task tests to be a bit more
robust for checking the basic usage of this task.

-Jaikiran


On 13/08/18 7:17 PM, Jaikiran Pai wrote:
> Yes, it looks like one of our changes broke this. We seem to just fetch
> the mail API jar(s) and no longer fetch the jars which includethe
> provider implementation(s). Can you please file a bug for this, in the
> Ant bugzilla?
>
> -Jaikiran
>
>
> On 13/08/18 7:13 PM, Simon IJskes - QCG wrote:
>> It looks like javax.mail-1.6.1.jar is missing.
>>
>> By manually copying this jar into the lib directory it works.
>>
>> Before that i've tried to add a dependency in lib/ant-javamail.pom and
>> running fetch again but that did not fix it:
>>
>> 
>>     com.sun.mail
>>     javax.mail
>>     1.6.1
>> 
>>
>>
>> On 08/13/2018 03:27 PM, Simon IJskes - QCG wrote:
>>> The jar files loaded during execution are:
>>>
>>> /home/sim/apache-ant-1.10.5/lib/ant-launcher.jar
>>> /home/sim/apache-ant-1.10.5/lib/ant-xz.jar
>>> /home/sim/apache-ant-1.10.5/lib/ant-apache-log4j.jar
>>> /home/sim/apache-ant-1.10.5/lib/ant-apache-bcel.jar
>>> /home/sim/apache-ant-1.10.5/lib/ant-swing.jar
>>> /home/sim/apache-ant-1.10.5/lib/ant-commons-logging.jar
>>> /home/sim/apache-ant-1.10.5/lib/javax.mail-api-1.6.1.jar
>>> /home/sim/apache-ant-1.10.5/lib/ant-junitlauncher.jar
>>> /home/sim/apache-ant-1.10.5/lib/activation-1.1.jar
>>> /home/sim/apache-ant-1.10.5/lib/ant-jdepend.jar
>>> /home/sim/apache-ant-1.10.5/lib/ant-apache-oro.jar
>>> /home/sim/apache-ant-1.10.5/lib/ant-apache-bsf.jar
>>> /home/sim/apache-ant-1.10.5/lib/ant-javamail.jar
>>> /home/sim/apache-ant-1.10.5/lib/ant-jmf.jar
>>> /home/sim/apache-ant-1.10.5/lib/ant-testutil.jar
>>> /home/sim/apache-ant-1.10.5/lib/ant-netrexx.jar
>>> /home/sim/apache-ant-1.10.5/lib/ant-junit.jar
>>> /home/sim/apache-ant-1.10.5/lib/ant-commons-net.jar
>>> /home/sim/apache-ant-1.10.5/lib/ant-junit4.jar
>>> /home/sim/apache-ant-1.10.5/lib/ant-antlr.jar
>>> /home/sim/apache-ant-1.10.5/lib/maven-ant-tasks-2.1.3.jar
>>> /home/sim/apache-ant-1.10.5/lib/ant-jai.jar
>>> /home/sim/apache-ant-1.10.5/lib/ant.jar
>>> /home/sim/apache-ant-1.10.5/lib/ant-apache-xalan2.jar
>>> /home/sim/apache-ant-1.10.5/lib/ant-jsch.jar
>>> /home/sim/apache-ant-1.10.5/lib/ant-apache-regexp.jar
>>> /home/sim/apache-ant-1.10.5/lib/ant-apache-resolver.jar
>>> /home/sim/apache-ant-1.10.5/lib/ant.jar
>>
>> -
>> 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: mail task

2018-08-13 Thread Jaikiran Pai
Yes, it looks like one of our changes broke this. We seem to just fetch
the mail API jar(s) and no longer fetch the jars which includethe
provider implementation(s). Can you please file a bug for this, in the
Ant bugzilla?

-Jaikiran


On 13/08/18 7:13 PM, Simon IJskes - QCG wrote:
> It looks like javax.mail-1.6.1.jar is missing.
>
> By manually copying this jar into the lib directory it works.
>
> Before that i've tried to add a dependency in lib/ant-javamail.pom and
> running fetch again but that did not fix it:
>
> 
>     com.sun.mail
>     javax.mail
>     1.6.1
> 
>
>
> On 08/13/2018 03:27 PM, Simon IJskes - QCG wrote:
>> The jar files loaded during execution are:
>>
>> /home/sim/apache-ant-1.10.5/lib/ant-launcher.jar
>> /home/sim/apache-ant-1.10.5/lib/ant-xz.jar
>> /home/sim/apache-ant-1.10.5/lib/ant-apache-log4j.jar
>> /home/sim/apache-ant-1.10.5/lib/ant-apache-bcel.jar
>> /home/sim/apache-ant-1.10.5/lib/ant-swing.jar
>> /home/sim/apache-ant-1.10.5/lib/ant-commons-logging.jar
>> /home/sim/apache-ant-1.10.5/lib/javax.mail-api-1.6.1.jar
>> /home/sim/apache-ant-1.10.5/lib/ant-junitlauncher.jar
>> /home/sim/apache-ant-1.10.5/lib/activation-1.1.jar
>> /home/sim/apache-ant-1.10.5/lib/ant-jdepend.jar
>> /home/sim/apache-ant-1.10.5/lib/ant-apache-oro.jar
>> /home/sim/apache-ant-1.10.5/lib/ant-apache-bsf.jar
>> /home/sim/apache-ant-1.10.5/lib/ant-javamail.jar
>> /home/sim/apache-ant-1.10.5/lib/ant-jmf.jar
>> /home/sim/apache-ant-1.10.5/lib/ant-testutil.jar
>> /home/sim/apache-ant-1.10.5/lib/ant-netrexx.jar
>> /home/sim/apache-ant-1.10.5/lib/ant-junit.jar
>> /home/sim/apache-ant-1.10.5/lib/ant-commons-net.jar
>> /home/sim/apache-ant-1.10.5/lib/ant-junit4.jar
>> /home/sim/apache-ant-1.10.5/lib/ant-antlr.jar
>> /home/sim/apache-ant-1.10.5/lib/maven-ant-tasks-2.1.3.jar
>> /home/sim/apache-ant-1.10.5/lib/ant-jai.jar
>> /home/sim/apache-ant-1.10.5/lib/ant.jar
>> /home/sim/apache-ant-1.10.5/lib/ant-apache-xalan2.jar
>> /home/sim/apache-ant-1.10.5/lib/ant-jsch.jar
>> /home/sim/apache-ant-1.10.5/lib/ant-apache-regexp.jar
>> /home/sim/apache-ant-1.10.5/lib/ant-apache-resolver.jar
>> /home/sim/apache-ant-1.10.5/lib/ant.jar
>
>
> -
> 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: mail task

2018-08-13 Thread Jaikiran Pai
Which vendor and version of Java is this?

-Jaikiran


On 13/08/18 6:39 PM, Simon IJskes - QCG wrote:
> I still have problems installing ant binary distribution (1.10.5) and
> using the email task.
>
> I've tried to complete the binary directories by running either:
>
> ant -f fetch.xml -Ddest=system
>
> or
>
> ant -f fetch.xml -Ddest=system javamail
>
>
> But then i still have (altough another) exception:
>
> build.xml:6: java.lang.NoClassDefFoundError:
> com/sun/mail/util/FolderClosedIOException
>
> at:
>
>      subject="Testemail"  >
>     
>     
>
> What am i missing here? I've tried with and without --noconfig
>
> Gr. 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: Jenkins-Builds failing

2018-08-13 Thread Jaikiran Pai
Noted. Just waiting for the infra team to sort out the access issue.

-Jaikiran


On 12/08/18 2:28 AM, Gintautas Grigelionis wrote:
> Hi Jan and Jaikiran,
>
> looks like IvyDE trunk build needs attention, too (SSL protocol failure
> when resolving Checkstyle).
>
> Thanks, Gintas
>
> On Wed, 8 Aug 2018 at 13:23, Jan Matèrne (jhm)  wrote:
>
>> Tried to change from "Ant 1.9.9" to "Ant (latest)".
>> An "Ant 1.10.1" or an "Ant 1.9.9" are the latest available named versions.
>>
>> Got an
>>   Access denied
>>   This job's current authorization strategy does not permit jhm to modify
>> the job configuration
>>
>> Asked in https://issues.apache.org/jira/browse/INFRA-16799 for
>> checking+fixing all of our jobs.
>>
>>
>> Jan
>>
>>> -Ursprüngliche Nachricht-
>>> Von: Jaikiran Pai [mailto:jaiki...@apache.org]
>>> Gesendet: Montag, 6. August 2018 06:45
>>> An: dev@ant.apache.org
>>> Betreff: Re: Jenkins-Builds failing
>>>
>>> Sure, will fix it this week. Right now, I don't have necessary
>>> permissions to edit it.
>>>
>>> -Jaikiran
>>>
>>>
>>> On 05/08/18 8:58 PM, Gintautas Grigelionis wrote:
>>>> There's one more Jenkins job failing due to outdated Ant, Ivy Check (
>>>> https://builds.apache.org/view/All/job/Ivy-check/).
>>>> Could you please check it, Jaikiran?
>>>>
>>>> Thanks, Gintas
>>>>
>>>> On Sun, 29 Jul 2018 at 15:13, Jaikiran Pai 
>>> wrote:
>>>>> 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
>>>>>
>>>>>
>>>
>>> -
>>> 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



[GitHub] ant pull request #67: Support for fork mode in junitlauncher

2018-08-09 Thread jaikiran
Github user jaikiran closed the pull request at:

https://github.com/apache/ant/pull/67


---

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



[GitHub] ant issue #67: Support for fork mode in junitlauncher

2018-08-09 Thread jaikiran
Github user jaikiran commented on the issue:

https://github.com/apache/ant/pull/67
  
>> Looks good at first glance, I'll have a more thorough look sometime 
before we cut the next release.

Thank you.

>> The new files need to have license headers added.

Will add them and setup my IDE correctly.


---

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



Re: Jenkins-Builds failing

2018-08-05 Thread Jaikiran Pai
Sure, will fix it this week. Right now, I don't have necessary
permissions to edit it.

-Jaikiran


On 05/08/18 8:58 PM, Gintautas Grigelionis wrote:
> There's one more Jenkins job failing due to outdated Ant, Ivy Check (
> https://builds.apache.org/view/All/job/Ivy-check/).
> Could you please check it, Jaikiran?
>
> Thanks, Gintas
>
> On Sun, 29 Jul 2018 at 15:13, Jaikiran Pai  wrote:
>
>> 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
>>
>>


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



[GitHub] ant pull request #67: Support for fork mode in junitlauncher

2018-08-05 Thread jaikiran
GitHub user jaikiran opened a pull request:

https://github.com/apache/ant/pull/67

Support for fork mode in junitlauncher

The commit here introduces support for launching the JUnit tests, through 
`junitlauncher` task, in forked mode. 

I decided to keep the fork aspects as a separate element instead of 
introducing multiple attribtues that are only applicable in forked mode. As 
such, each `test` or `testclasses` element of the `junitlauncher` task can now 
have a nested `fork` element indicating that those tests need to be launced in 
a forked JVM. The characteristics of the forked JVM are determined by the 
attribtues and nested elements of the `fork` element. 

I have added support for most of the fork attribtues that are applicable 
for the legacy junit task (I also checked the java task to make sure the JVM 
launching characteristics are captured in the fork element's attributes). I am 
working on the manual updates to explain this support so this PR doesn't 
include that part, but here's what it will end up looking like:
```







...

...

 
 

...




...

...


```
From an implementation detail point of view, the core logic of launching 
the tests through the JUnit platform remains intact (of course, the code itself 
has been moved into an internal class to be shared in forked and non-forked 
mode). An internal contract `LaunchDefinition` has been introduced so that the 
launching aspects can be captured in this interface. Non-forked and forked mode 
execution will internally construct an instance of the `LaunchDefinition`. 

A `StandaloneLauncher` (an internal detail of this task) has been 
introduced to be the entry point with a `main` method for forked mode 
execution. The responsibility of this class is to parse the arguments and 
construct the `LaunchDefinition` and then just pass it over to the 
`LauncherSupport` (interal impl detail). We pass around the launch definition 
to the forked mode launcher in the form of an xml which captures the necessary 
details like what tests to launch and what listeners to use. Note that this xml 
is an internal detail and can change over releases. I decided to capture these 
details in a file and pass it to the `main` method instead of passing mutliple 
different arguments for two reasons:

  - Reduce the command line length when executing these forked tests
  - Allow hierarchical representation of the launch definition details, 
like which listener is for which test.

I have tested the fork support manually, but this needs more automated 
tests. I'm in the process of writing those tests and also updating the manual 
of this task. I wanted to get any review comments on these changes in the 
meantime.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/jaikiran/ant junit5-fork

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ant/pull/67.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #67


commit bd6480fc6184da09546c441413038087b6df0ed3
Author: Jaikiran Pai 
Date:   2018-07-25T13:53:00Z

Support for fork mode in junitlauncher




---

-
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...

2018-08-01 Thread jaikiran
Github user jaikiran commented on the issue:

https://github.com/apache/ant-ivy/pull/73
  
>> Should I reopen PR?


---

-
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...

2018-08-01 Thread jaikiran
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...

2018-08-01 Thread jaikiran
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...

2018-08-01 Thread jaikiran
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...

2018-08-01 Thread jaikiran
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.

2018-07-29 Thread jaikiran
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



  1   2   3   4   5   6   >