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 .
>  * Changes in this build
>   
> 
>  * 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  
>    istargeted for JDK 13.
>  * JEP 351: ZGC: Uncommit Unused Memory
>     istargeted for JDK 13
>  * JEP 353: Reimplement the Legacy Socket API
>     moved to Candidate
>  * JEP 354: Switch Expressions  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

The Apache Ant Team is pleased to announce the release of Apache Ant 1.10.6.

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

This, Ant 1.10.6 release, consists several bug fixes as well as
enhancements, including, but not limited to:

- junitlauncher task now supports fork mode, to launch the tests in a
forked JVM.
- New tasks jmod and link have been introduced to support jmod and jlink
tools of JDK 9+.

Source and binary distributions are available for download from the
Apache Ant download site:

https://ant.apache.org/bindownload.cgi
https://ant.apache.org/srcdownload.cgi

When downloading, please verify signatures using the KEYS file available
at the above location when downloading the release.

Changes in 1.10.6 include:
==

Changes that could break older environments:
---

 * image task no longer works on Java 9+ because internal classes
   supporting Java Advanced Imaging are removed; imageio task (based on
   ImageIO and AWT) is provided as a replacement.

 * junitlauncher task has changed the class names and package names of
   the task as well as some of the supporting classes of that task. If
   any code depended on these class or package names, they will have to
   be updated to reference these newly named classes. This however,
   doesn't impact build scripts if their reference to junitlauncher task
   was merely through the use of the junitlauncher> element.

 * 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

 * Fixes an issue in junitreport task, which used to throw a
   java.net.MalformedURLException when saxon was used on Windows OS.
   Bugzilla Report 62594

 * 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

 * sync task, in some cases on case insensitive file systems, would consider
   a file in a destination directory to be orphaned and would delete it.
   This task has now been fixed to infer the case sensitivity of the
filesystem
   of the destination directory.
   Bugzilla Report 62890

 * Fixes a potential java.util.ConcurrentModificationException in
   org.apache.tools.ant.Project#getCopyOfReferences.
   Github Pull Request #81

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

 * The isreachable condition could in some cases return true even if the
   actual address could potentially be unreachable. This is now fixed
   and the resolved address is actually checked for reachability.

 * Fixes an issue where scp transfer completion tracking wasn't being
   triggered for 100% completion.
   Github Pull Request #91


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.

 * junitlauncher task now supports running tests in a forked JVM. More
   details available in the junitlauncher task manual.

 * 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

 * properties used or set by BuildFileTask/BuildFileRule are documented
   in MagicTestNames. A new magic property, ant.test.basedir.ignore, is
   introduced for cases where Ant projects set up for test purposes
   must ignore basedir set externally by test harness.

 * a new CharSet type is provided for encoding or charset attributes in
   tasks that must deal with different character encodings in files,
   file names and other string resources.

 * org.apache.tools.ant.AntClassLoader is now multi-release jar aware.
   Starting Java 9, jar files can be packaged as multi-release 

[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 .
>  * Changes in this build
>   
> 
>  * Release notes [1]
>
> *Significant changes since the last availability email*
>
>  * build 16 - Update the default enabled cipher suites preference
>    (JDK-8163326 )
>  * build 16 - Add new keytool -showinfo -tls command for displaying TLS
>    configuration information (JDK-8219861
>    )
>  * build 15  -*New Japanese Era Name **(JDK-8205432
>    )*
>  * build 15  - Accessing REIWA era in java.time.chrono.JapaneseEra
>    (JDK-8174268 )
>  * build 15  - Duplicated RSA services are no longer supported by
>    SunJSSE provider (JDK-8220016
>    )
>  * build 15  - Use server cipher suites preference by default
>    (JDK-8168261 )
>  * build 15  - The Swing Motif Look and Feel is deprecated and
>    unsupported on macOS (JDK-8177960
>    )
>  * build 15  - Remove support for javadoc "frames" mode (JDK-8215599
>    )
>
> Bug fix reported by Open Source Projects  :
>
>  * build 15  - Unable to read certain PKCS12 keystores from
>    SequenceInputStream (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 . [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
>    .
>  * Changes in this build
>   
> 
>  * 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
>    , 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
>    
>
> *Quality Outreach report for **March 2019*
>
>  * The report for March 2019 is available here
>   
> 
>  * Thanks to all those contributed !
>
> *Recent Blog:* 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.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
>>
>>  
>>  
>> diff --git a/manual/Tasks/scriptdef.html b/manual/Tasks/scriptdef.html
>> index 384d6c5..798d5c8 100644
>> --- a/manual/Tasks/scriptdef.html
>> +++ b/manual/Tasks/scriptdef.html
>> @@ -226,7 +226,7 @@ through them
>>  + filesets.get(i).getDir(project));
>>  }
>>]]
>> -/scriptdef
>> +/scriptdef
>>
>>  scripttest2
>>fileset dir=src/
>> diff --git a/manual/Tasks/serverdeploy.html b/manual/Tasks/serverdeploy.html
>> index 545f0b1..a09d756 100644
>> --- a/manual/Tasks/serverdeploy.html
>> +++ 

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
>    ) 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
>    ].
>
>  o Build 28: 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.
>   
> 
>
> **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 .
>  * Release Notes updates
>  * Build 8
>  o GraphicsEnvironment.getCenterPoint()/getMaximumWindowBounds()
>    are unified across the platforms (JDK-8214918
>    )
>  o The experimental FIPS 140 compliant mode has been removed from
>    the SunJSSE provider. (JDK-8217835
>    )
>  * Build 7
>  o Change DOM parser to not resolve EntityReference and add Text
>    node with
>    DocumentBuilderFactory.setExpandEntityReferences(false)
>    (JDK-8206132 )
>  * Build 6
>  o Base64.Encoder and Base64.Decoder methods can throw
>    OutOfMemoryError (JDK-8210583
>    )
>  * Changes in this build
>   
> 
>  * FOSS Bugs fixed in recent builds
>  o Build 6 : JDK-8216970
>     : condy
>    causes JVM crash
>  o Build 7: 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
>  and
> , 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
> , but that requires logging into
> , 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



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



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



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



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
>> --- a/src/etc/checkstyle/checkstyle-frames-sortby-check.xsl
>> +++ b/src/etc/checkstyle/checkstyle-frames-sortby-check.xsl
>> @@ -22,7 +22,7 @@
>> -->
>>
>> 
>> -
>> +
>>
>> 
>> 
>> @@ -43,7 +43,7 @@
>> 
>> 
>>
>> -
>> +
>> 
>> 
>> 
>> @@ -76,15 +76,15 @@
>>
>>
>> 
>> 
>>
>>
>>
>>  
>> +Generates the navigation bar.
>> +-->
>> 
>> 
>>

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**(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
>     (b27)
>  * Apache Tomcat   -JDK-8208642
>    (b27)
>  * JBoss Netty - JDK-8207029
>     (b23),
>    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  -
>    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
>     build or a JDK 11 EA
>     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
> 
> [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 
> 
>
> --
> 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 
> 
> [WS-CLEANUP] Deleting project workspace...
> ERROR: [WS-CLEANUP] Cannot delete workspace: remote file operation failed: 
> 
>  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: 
> 
>  -> 
> 
> ERROR: Cannot delete workspace: remote file operation failed: 
> 
>  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: 
> 
>  -> 
> 
> 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, 
> 
>  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



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 
> 
>
> 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, Skipped: 0, Time elapsed: 
> 0,922 sec
> [junit] Running org.apache.ivy.core.install.InstallTest
> [junit] Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
> 2,83 sec
> [junit] Running 
> org.apache.ivy.core.module.descriptor.DefaultDependencyDescriptorTest
>  

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



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



Re: Jenkins-Builds failing

2018-07-29 Thread Jaikiran Pai
I would like to test/import a few more projects (that Nicolas mentioned
in one the mails) locally into the latest upstream version of the IDE,
before starting a release. I have only tested a few so far.

-Jaikiran

On 28/07/18 2:28 PM, Gintautas Grigelionis wrote:
> Thanks, Jaikiran. Would you be willing to restart the release process
> for IvyDE now? Gintas On Fri, 27 Jul 2018 at 15:43, Jaikiran Pai
>  wrote:
>> On 25/07/18 6:45 PM, Jaikiran Pai wrote:
>>> Almost all jobs that I know of have been taken care of now. There's
>>> a "Ivy-tests-Windows" job which is pending, but for that I need some
>>> help from infra team. I am discussing it with them separately and I
>>> expect it to be resolved soon. I'll fix that job tomorrow. 
>> This is now done too. -Jaikiran
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional
>> commands, e-mail: dev-h...@ant.apache.org 
>


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



Re: Jenkins-Builds failing

2018-07-27 Thread Jaikiran Pai


On 25/07/18 6:45 PM, Jaikiran Pai wrote:
> Almost all jobs that I know of have been taken care of now. There's a
> "Ivy-tests-Windows" job which is pending, but for that I need some help
> from infra team. I am discussing it with them separately and I expect it
> to be resolved soon. I'll fix that job tomorrow.
This is now done too.

-Jaikiran

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



Re: Jenkins-Builds failing

2018-07-25 Thread Jaikiran Pai
Almost all jobs that I know of have been taken care of now. There's a
"Ivy-tests-Windows" job which is pending, but for that I need some help
from infra team. I am discussing it with them separately and I expect it
to be resolved soon. I'll fix that job tomorrow.

-Jaikiran


On 25/07/18 11:07 AM, Jaikiran Pai wrote:
> There are a few more jobs that need to be reconfigured a bit to get them
> working. I'm working with infra team to have that sorted out. Please
> ignore the failure mails from those jobs for now.
>
> -Jaikiran
>
> On 25/07/18 10:30 AM, Jaikiran Pai wrote:
>> I've committed a change[1] to handle this in the part where we trigger
>> the tutorial run. [1]
>> https://github.com/apache/ant-ivy/commit/43ddccb859b94c79350ece7520af4c991c2bb5e6
>> -Jaikiran On 24/07/18 10:53 PM, Gintautas Grigelionis wrote:
>>> Thank you for all attempts, the failure occurs in run-tutorial macro
>>> (forked JVM). What would be the best way to forwarding Java
>>> arguments/system properties? Gintas On Tue, 24 Jul 2018 at 09:14,
>>> Gintautas Grigelionis  wrote:
>>>> It must be set as Java parameter, not Ant parameter. Gintas On Tue,
>>>> 24 Jul 2018 at 08:38, Jan Matèrne (jhm)  wrote:
>>>>> "Looks like someone called 'hibou' restricted the job to
>>>>> themselves. (See screenshot attached to this ticket)" This was a
>>>>> "run as hibou" configuration. @Nicolas: What was the reason to add
>>>>> that? Is it required? Gavin removed that part and I could add the
>>>>> https.protocols=TLSv1.2 parameter. Job restarted. Jan
>>>>>> -Ursprüngliche Nachricht- Von: Jan Matèrne (jhm)
>>>>>> [mailto:apa...@materne.de] Gesendet: Sonntag, 22. Juli 2018 12:54
>>>>>> An: 'Ant Developers List' Betreff: AW: Jenkins-Builds failing
>>>>>> Checked by myself that a PMC chair could do (AFAIK). Opened a
>>>>>> ticket https://issues.apache.org/jira/browse/INFRA-16799 Jan
>>>>>>> -Ursprüngliche Nachricht- Von: Gintautas Grigelionis
>>>>>>> [mailto:g.grigelio...@gmail.com] Gesendet: Sonntag, 22. Juli 2018
>>>>>>> 10:48 An: Ant Developers List Betreff: Re: Jenkins-Builds failing
>>>>>>> Should we ask infra if nobody else knows about Jenkins
>>>>>>> authorization? Gintas On Fri, 20 Jul 2018 at 11:26, Jan Matèrne
>>>>>>> (jhm)  wrote:
>>>>>>>> Neither do I. Jan
>>>>>>>>> -Ursprüngliche Nachricht- Von: Jaikiran Pai
>>>>>>>>> [mailto:jai.forums2...@gmail.com] Gesendet: Freitag, 20. Juli
>>>>>>>>> 2018 10:15 An: dev@ant.apache.org Betreff: Re: Jenkins-Builds
>>>>>>>>> failing Now that I checked the job's logs, I think that's true.
>>>>>>>>> We had this issue in Ant too (not really against Maven repos,
>>>>>>>>> but HTTPS hosted Apache infrastructure). I tried setting that
>>>>>>>>> property in the job, but I too don't have the necessary
>>>>>>>>> authorization. I 
>>>>>> don't
>>>>>>>>> remember if I ever had those permissions or if it's something 
>>>>>> that
>>>>>>>>> changed with the recent Jenkins upgrade. -Jaikiran On 20/07/18
>>>>>>>>> 1:34 PM, Gintautas Grigelionis wrote:
>>>>>>>>>> My hypothesis is that Java 7 must have TLS version forced to 
>>>>>> 1.2
>>>>>>>>>> in order to avoid protocol errors when downloading new
>>>>>>>>>> binaries from Maven Central because earlier versions are
>>>>>>>>>> disabled [1] (and TLS 1.0 is the default in Java 7). Gintas 1.
>>>>>>>>>> https://blog.pcisecuritystandards.org/are-you-ready-for-30- 
>>>>>> june-
>>>>>>> 20
>>>>>>>>>> 18- 
>>>>>>>>> s
>>>>>>>>>> ayin-goodbye-to-ssl-early-tls On Fri, 20 Jul 2018 at 09:31,
>>>>>>>>>> Jaikiran Pai  
>>>>>>>>> wrote:
>>>>>>>>>>> Haven't checked the job, but why is this system property 
>>>>>>> required
>>>>>>>>>>> to be set? -Jaikiran On 20/07/18 12:51 AM, Gintautas
>>>>>>>>>>> Grigelionis wrote:
>

Re: Jenkins-Builds failing

2018-07-24 Thread Jaikiran Pai
There are a few more jobs that need to be reconfigured a bit to get them
working. I'm working with infra team to have that sorted out. Please
ignore the failure mails from those jobs for now.

-Jaikiran

On 25/07/18 10:30 AM, Jaikiran Pai wrote:
> I've committed a change[1] to handle this in the part where we trigger
> the tutorial run. [1]
> https://github.com/apache/ant-ivy/commit/43ddccb859b94c79350ece7520af4c991c2bb5e6
> -Jaikiran On 24/07/18 10:53 PM, Gintautas Grigelionis wrote:
>> Thank you for all attempts, the failure occurs in run-tutorial macro
>> (forked JVM). What would be the best way to forwarding Java
>> arguments/system properties? Gintas On Tue, 24 Jul 2018 at 09:14,
>> Gintautas Grigelionis  wrote:
>>> It must be set as Java parameter, not Ant parameter. Gintas On Tue,
>>> 24 Jul 2018 at 08:38, Jan Matèrne (jhm)  wrote:
>>>> "Looks like someone called 'hibou' restricted the job to
>>>> themselves. (See screenshot attached to this ticket)" This was a
>>>> "run as hibou" configuration. @Nicolas: What was the reason to add
>>>> that? Is it required? Gavin removed that part and I could add the
>>>> https.protocols=TLSv1.2 parameter. Job restarted. Jan
>>>>> -Ursprüngliche Nachricht- Von: Jan Matèrne (jhm)
>>>>> [mailto:apa...@materne.de] Gesendet: Sonntag, 22. Juli 2018 12:54
>>>>> An: 'Ant Developers List' Betreff: AW: Jenkins-Builds failing
>>>>> Checked by myself that a PMC chair could do (AFAIK). Opened a
>>>>> ticket https://issues.apache.org/jira/browse/INFRA-16799 Jan
>>>>>> -Ursprüngliche Nachricht- Von: Gintautas Grigelionis
>>>>>> [mailto:g.grigelio...@gmail.com] Gesendet: Sonntag, 22. Juli 2018
>>>>>> 10:48 An: Ant Developers List Betreff: Re: Jenkins-Builds failing
>>>>>> Should we ask infra if nobody else knows about Jenkins
>>>>>> authorization? Gintas On Fri, 20 Jul 2018 at 11:26, Jan Matèrne
>>>>>> (jhm)  wrote:
>>>>>>> Neither do I. Jan
>>>>>>>> -Ursprüngliche Nachricht- Von: Jaikiran Pai
>>>>>>>> [mailto:jai.forums2...@gmail.com] Gesendet: Freitag, 20. Juli
>>>>>>>> 2018 10:15 An: dev@ant.apache.org Betreff: Re: Jenkins-Builds
>>>>>>>> failing Now that I checked the job's logs, I think that's true.
>>>>>>>> We had this issue in Ant too (not really against Maven repos,
>>>>>>>> but HTTPS hosted Apache infrastructure). I tried setting that
>>>>>>>> property in the job, but I too don't have the necessary
>>>>>>>> authorization. I 
>>>>> don't
>>>>>>>> remember if I ever had those permissions or if it's something 
>>>>> that
>>>>>>>> changed with the recent Jenkins upgrade. -Jaikiran On 20/07/18
>>>>>>>> 1:34 PM, Gintautas Grigelionis wrote:
>>>>>>>>> My hypothesis is that Java 7 must have TLS version forced to 
>>>>> 1.2
>>>>>>>>> in order to avoid protocol errors when downloading new
>>>>>>>>> binaries from Maven Central because earlier versions are
>>>>>>>>> disabled [1] (and TLS 1.0 is the default in Java 7). Gintas 1.
>>>>>>>>> https://blog.pcisecuritystandards.org/are-you-ready-for-30- 
>>>>> june-
>>>>>> 20
>>>>>>>>> 18- 
>>>>>>>> s
>>>>>>>>> ayin-goodbye-to-ssl-early-tls On Fri, 20 Jul 2018 at 09:31,
>>>>>>>>> Jaikiran Pai  
>>>>>>>> wrote:
>>>>>>>>>> Haven't checked the job, but why is this system property 
>>>>>> required
>>>>>>>>>> to be set? -Jaikiran On 20/07/18 12:51 AM, Gintautas
>>>>>>>>>> Grigelionis wrote:
>>>>>>>>>>> I'd like to add a Java option to Ivy builds
>>>>>>>>>>> -Dhttps.protocols=TLSv1.2 
>>>>>>>>>> but I
>>>>>>>>>>> get This job's current authorization strategy does not permit 
>>>>>> gintas
>>>>>>>>>>> to 
>>>>>>>>>> modify
>>>>>>>>>>> the job configuration Gintas On Tue, 3 Jul 2018 at 19:09,
>>>>>>>>>>> Gintautas Gr

Re: Jenkins-Builds failing

2018-07-24 Thread Jaikiran Pai
I've committed a change[1] to handle this in the part where we trigger
the tutorial run.


[1]
https://github.com/apache/ant-ivy/commit/43ddccb859b94c79350ece7520af4c991c2bb5e6

-Jaikiran


On 24/07/18 10:53 PM, Gintautas Grigelionis wrote:
> Thank you for all attempts, the failure occurs in run-tutorial macro
> (forked JVM).
> What would be the best way to forwarding Java arguments/system properties?
>
> Gintas
>
> On Tue, 24 Jul 2018 at 09:14, Gintautas Grigelionis 
> wrote:
>
>> It must be set as Java parameter, not Ant parameter.
>>
>> Gintas
>>
>> On Tue, 24 Jul 2018 at 08:38, Jan Matèrne (jhm)  wrote:
>>
>>> "Looks like someone called 'hibou' restricted the job to themselves. (See
>>> screenshot attached to this ticket)"
>>>
>>> This was a "run as hibou" configuration.
>>>
>>> @Nicolas: What was the reason to add that? Is it required?
>>>
>>>
>>> Gavin removed that part and I could add the https.protocols=TLSv1.2
>>> parameter.
>>> Job restarted.
>>>
>>>
>>> Jan
>>>
>>>
>>>> -Ursprüngliche Nachricht-
>>>> Von: Jan Matèrne (jhm) [mailto:apa...@materne.de]
>>>> Gesendet: Sonntag, 22. Juli 2018 12:54
>>>> An: 'Ant Developers List'
>>>> Betreff: AW: Jenkins-Builds failing
>>>>
>>>> Checked by myself that a PMC chair could do (AFAIK).
>>>> Opened a ticket
>>>> https://issues.apache.org/jira/browse/INFRA-16799
>>>>
>>>> Jan
>>>>
>>>>> -Ursprüngliche Nachricht-
>>>>> Von: Gintautas Grigelionis [mailto:g.grigelio...@gmail.com]
>>>>> Gesendet: Sonntag, 22. Juli 2018 10:48
>>>>> An: Ant Developers List
>>>>> Betreff: Re: Jenkins-Builds failing
>>>>>
>>>>> Should we ask infra if nobody else knows about Jenkins authorization?
>>>>>
>>>>> Gintas
>>>>>
>>>>> On Fri, 20 Jul 2018 at 11:26, Jan Matèrne (jhm) 
>>>>> wrote:
>>>>>
>>>>>> Neither do I.
>>>>>>
>>>>>> Jan
>>>>>>
>>>>>>> -Ursprüngliche Nachricht-
>>>>>>> Von: Jaikiran Pai [mailto:jai.forums2...@gmail.com]
>>>>>>> Gesendet: Freitag, 20. Juli 2018 10:15
>>>>>>> An: dev@ant.apache.org
>>>>>>> Betreff: Re: Jenkins-Builds failing
>>>>>>>
>>>>>>> Now that I checked the job's logs, I think that's true. We had
>>>>>>> this issue in Ant too (not really against Maven repos, but HTTPS
>>>>>>> hosted Apache infrastructure). I tried setting that property in
>>>>>>> the job, but I too don't have the necessary authorization. I
>>>> don't
>>>>>>> remember if I ever had those permissions or if it's something
>>>> that
>>>>>>> changed with the recent Jenkins upgrade.
>>>>>>>
>>>>>>> -Jaikiran
>>>>>>>
>>>>>>>
>>>>>>> On 20/07/18 1:34 PM, Gintautas Grigelionis wrote:
>>>>>>>> My hypothesis is that Java 7 must have TLS version forced to
>>>> 1.2
>>>>>>>> in order to avoid protocol errors when downloading new binaries
>>>>>>>> from Maven Central because earlier versions are disabled [1]
>>>>>>>> (and TLS 1.0 is the default in Java 7).
>>>>>>>>
>>>>>>>> Gintas
>>>>>>>>
>>>>>>>> 1.
>>>>>>>> https://blog.pcisecuritystandards.org/are-you-ready-for-30-
>>>> june-
>>>>> 20
>>>>>>>> 18-
>>>>>>> s
>>>>>>>> ayin-goodbye-to-ssl-early-tls
>>>>>>>>
>>>>>>>> On Fri, 20 Jul 2018 at 09:31, Jaikiran Pai
>>>>>>>> 
>>>>>>> wrote:
>>>>>>>>> Haven't checked the job, but why is this system property
>>>>> required
>>>>>>>>> to be set?
>>>>>>>>>
>>>>>>>>> -Jaikiran
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 20/07/18 12:51 AM, Gintautas Grigelionis wrote:
>&g

Re: Jenkins-Builds failing

2018-07-20 Thread Jaikiran Pai
Now that I checked the job's logs, I think that's true. We had this
issue in Ant too (not really against Maven repos, but HTTPS hosted
Apache infrastructure). I tried setting that property in the job, but I
too don't have the necessary authorization. I don't remember if I ever
had those permissions or if it's something that changed with the recent
Jenkins upgrade.

-Jaikiran


On 20/07/18 1:34 PM, Gintautas Grigelionis wrote:
> My hypothesis is that Java 7 must have TLS version forced to 1.2 in order
> to avoid protocol errors when downloading new binaries from Maven Central
> because earlier versions are disabled [1] (and TLS 1.0 is the default in
> Java 7).
>
> Gintas
>
> 1.
> https://blog.pcisecuritystandards.org/are-you-ready-for-30-june-2018-sayin-goodbye-to-ssl-early-tls
>
> On Fri, 20 Jul 2018 at 09:31, Jaikiran Pai  wrote:
>
>> Haven't checked the job, but why is this system property required to be
>> set?
>>
>> -Jaikiran
>>
>>
>> On 20/07/18 12:51 AM, Gintautas Grigelionis wrote:
>>> I'd like to add a Java option to Ivy builds -Dhttps.protocols=TLSv1.2
>> but I
>>> get
>>> This job's current authorization strategy does not permit gintas to
>> modify
>>> the job configuration
>>>
>>> Gintas
>>>
>>> On Tue, 3 Jul 2018 at 19:09, Gintautas Grigelionis <
>> g.grigelio...@gmail.com>
>>> wrote:
>>>
>>>> Ant nightly is stuck on archiving for 30 hours now.
>>>> It should be escalated, I believe that could have something to do with
>> the
>>>> last upgrade of Jenkins.
>>>>
>>>> Gintas
>>>>
>>>> On Mon, 2 Jul 2018 at 14:18, Jan Matèrne  wrote:
>>>>
>>>>> Several of our Jenkins builds are failing:
>>>>>
>>>>>
>>>>>
>>>>> IvyDE:
>>>>>
>>>>> https://builds.apache.org/view/A/view/Ant/job/IvyDE/
>>>>>
>>>>> https://builds.apache.org/view/A/view/Ant/job/IvyDE/lastBuild/console
>>>>>
>>>>> Can't get
>>>>>
>>>>>
>> http://download.eclipse.org/webtools/downloads/drops/R3.4.2/R-3.4.2-20130208
>>>>> 151217/wtp4x-R-3.4.2-20130208151217.zip
>>>>> <
>> http://download.eclipse.org/webtools/downloads/drops/R3.4.2/R-3.4.2-20130208151217/wtp4x-R-3.4.2-20130208151217.zip
>>>>> to
>>>>>
>>>>>
>> /home/jenkins/jenkins-slave/workspace/IvyDE/dependencies/wtp4x-R-3.4.2-20130
>>>>> 208151217.zip
>>>>>
>>>>>
>>>>>
>>>>> The source URL gives a 404.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> AntLib - AntUnit
>>>>>
>>>>> https://builds.apache.org/view/A/view/Ant/job/AntLib-antunit/
>>>>>
>>>>>
>>>>>
>> https://builds.apache.org/view/A/view/Ant/job/AntLib-antunit/lastBuild/conso
>>>>> le
>>>>>
>>>>> [ivy:resolve]   Server access error at url
>>>>>
>>>>>
>> https://repo1.maven.org/maven2/org/apache/ant/ant-testutil/1.8.1/ant-testuti
>>>>> l-1.8.1.pom
>>>>> <
>> https://repo1.maven.org/maven2/org/apache/ant/ant-testutil/1.8.1/ant-testutil-1.8.1.pom
>>>>> (javax.net.ssl.SSLException: Received fatal alert:
>>>>> protocol_version)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> AntLib - SVN
>>>>>
>>>>> same problem as for AU
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Ivy
>>>>>
>>>>> https://builds.apache.org/view/A/view/Ant/job/Ivy/
>>>>>
>>>>> https://builds.apache.org/view/A/view/Ant/job/Ivy/lastBuild/console
>>>>>
>>>>> same problem as for AU
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Ant Nightly
>>>>>
>>>>> https://builds.apache.org/view/A/view/Ant/job/Ant_Nightly/
>>>>>
>>>>>
>>>>>
>> https://builds.apache.org/view/A/view/Ant/job/Ant_Nightly/lastBuild/console
>>>>> all runs fine, but "Archiving artifacts" requires lt of time …
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Ideas?
>>>>>
>>>>>
>>>>>
>>>>> Jan
>>>>>
>>>>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
>> For additional commands, e-mail: dev-h...@ant.apache.org
>>
>>


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



Re: Jenkins-Builds failing

2018-07-20 Thread Jaikiran Pai
Haven't checked the job, but why is this system property required to be set?

-Jaikiran


On 20/07/18 12:51 AM, Gintautas Grigelionis wrote:
> I'd like to add a Java option to Ivy builds -Dhttps.protocols=TLSv1.2 but I
> get
> This job's current authorization strategy does not permit gintas to modify
> the job configuration
>
> Gintas
>
> On Tue, 3 Jul 2018 at 19:09, Gintautas Grigelionis 
> wrote:
>
>> Ant nightly is stuck on archiving for 30 hours now.
>> It should be escalated, I believe that could have something to do with the
>> last upgrade of Jenkins.
>>
>> Gintas
>>
>> On Mon, 2 Jul 2018 at 14:18, Jan Matèrne  wrote:
>>
>>> Several of our Jenkins builds are failing:
>>>
>>>
>>>
>>> IvyDE:
>>>
>>> https://builds.apache.org/view/A/view/Ant/job/IvyDE/
>>>
>>> https://builds.apache.org/view/A/view/Ant/job/IvyDE/lastBuild/console
>>>
>>> Can't get
>>>
>>> http://download.eclipse.org/webtools/downloads/drops/R3.4.2/R-3.4.2-20130208
>>> 151217/wtp4x-R-3.4.2-20130208151217.zip
>>> 
>>> to
>>>
>>> /home/jenkins/jenkins-slave/workspace/IvyDE/dependencies/wtp4x-R-3.4.2-20130
>>> 208151217.zip
>>>
>>>
>>>
>>> The source URL gives a 404.
>>>
>>>
>>>
>>>
>>>
>>> AntLib - AntUnit
>>>
>>> https://builds.apache.org/view/A/view/Ant/job/AntLib-antunit/
>>>
>>>
>>> https://builds.apache.org/view/A/view/Ant/job/AntLib-antunit/lastBuild/conso
>>> le
>>>
>>> [ivy:resolve]   Server access error at url
>>>
>>> https://repo1.maven.org/maven2/org/apache/ant/ant-testutil/1.8.1/ant-testuti
>>> l-1.8.1.pom
>>> 
>>> (javax.net.ssl.SSLException: Received fatal alert:
>>> protocol_version)
>>>
>>>
>>>
>>>
>>>
>>> AntLib - SVN
>>>
>>> same problem as for AU
>>>
>>>
>>>
>>>
>>>
>>> Ivy
>>>
>>> https://builds.apache.org/view/A/view/Ant/job/Ivy/
>>>
>>> https://builds.apache.org/view/A/view/Ant/job/Ivy/lastBuild/console
>>>
>>> same problem as for AU
>>>
>>>
>>>
>>>
>>>
>>> Ant Nightly
>>>
>>> https://builds.apache.org/view/A/view/Ant/job/Ant_Nightly/
>>>
>>>
>>> https://builds.apache.org/view/A/view/Ant/job/Ant_Nightly/lastBuild/console
>>>
>>> all runs fine, but "Archiving artifacts" requires lt of time …
>>>
>>>
>>>
>>>
>>>
>>> Ideas?
>>>
>>>
>>>
>>> Jan
>>>
>>>


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



[ANNOUNCE] Apache Ant 1.9.13 and 1.10.5 Released

2018-07-15 Thread Jaikiran Pai
The Apache Ant Team is pleased to announce the releases of Apache Ant
1.9.13 and 1.10.5.

The Apache Ant team currently maintains two lines of development. The
1.9.x releases require Java5 at runtime and 1.10.x requires Java8 at
runtime. Both lines are based off of Ant 1.9.7 and the 1.9.x releases
are mostly bug fix releases while additional new features are developed
for 1.10.x. We recommend using 1.10.5 unless you are required to use
versions of Java prior to Java8 during the build process.

Ant 1.10.5 contains a superset of 1.9.13 - with the exception of a few
tasks and features that no longer work with Java8 anyway (like the apt
task).

Both releases are mostly bug fix releases with few new features added.
Both 1.9.13 and 1.10.5 fix a regression in the "get" task and also
address a remaining issue with unjar, untar and unzip tasks where they
would end up extracting content outside of the destination directory.
1.10.5 also introduces an enhancement to the "java" task to allow
launching single-file source programs, a Java language feature that is
introduced in the upcoming Java 11 release.

Source and binary distributions are available for download from the
Apache Ant download site:

https://ant.apache.org/bindownload.cgi
https://ant.apache.org/srcdownload.cgi

When downloading, please verify signatures by following the instructions
noted in the "Verify Releases" section at the above locations.

Changes in 1.10.5 include:
==

Fixed bugs:
---

 * Fixes a regression in the "get" task where redirects
   from a HTTP resource to a HTTPS resource started throwing
   an exception.
   Bugzilla Report 62499

 * the new allowFilesToEscapeDest didn't work when set to false and
   archive entries contained relative paths with so many ".."
   segnments that the resulting path would go beyond the file system
   root.
   Bugzilla Report 62502

Other changes:
--
 * Java task now accepts a "sourcefile" attribute to allow single file
   source program execution, a feature that is introduced in Java 11.

Changes in 1.9.13 include:
==

Fixed bugs:
---

 * Fixes a regression in the "get" task where redirects
   from a HTTP resource to a HTTPS resource started throwing
   an exception.
   Bugzilla Report 62499

 * the new allowFilesToEscapeDest didn't work when set to false and
   archive entries contained relative paths with so many ".."
   segnments that the resulting path would go beyond the file system
   root.
   Bugzilla Report 62502


For complete information on Ant, including instructions on how to submit
bug reports, patches, or suggestions for improvement, see the Apache Ant
website https://ant.apache.org/

-Jaikiran Pai, on behalf of the Apache Ant community




signature.asc
Description: OpenPGP digital signature


Re: [VOTE] Release Ant 1.10.5 based on RC1

2018-07-11 Thread Jaikiran Pai

+1

- Downloaded the .tar.gz from https://dist.apache.org/repos/dist/dev/ant/

- Extracted locally

- Checked the NOTICE and WHATSNEW files. Looks fine.

- Checked some random manuals. Looks fine.

- Checked the javac task manual. Looks fine.

- Tested the following build script to verify that it fails with a 
previous version of 1.10.x and now passes in 1.10.5:



    
        src="http://downloads.sourceforge.net/easymock/easymock-3.2.zip; 
dest="${basedir}/downloaded/"/>

    



- Tested the following build script to verify that the new "sourcefile" 
feature of Java task works:



    
        
    



A.java:

public class A {
    public static void main(final String[] args) throws Exception {
        System.out.println("Hello Ant 1.10.5!");
    }
}

Worked fine.

-Jaikiran





On 10/07/18 3:25 PM, Stefan Bodewig wrote:

Hi all

I've created a new release candidate for 1.10.5 with a few bug fixes and
and the "single source executable" feature for Java11.

git tag: ANT_1.10.5_RC1
  on commit: c0848d2c6
tarballs: https://dist.apache.org/repos/dist/dev/ant/
  revision: 28015
Maven artifacts:
  
https://repository.apache.org/content/repositories/orgapacheant-1035/org/apache/ant/

This Vote will be open at least for 72 hours and close no earlier than
2018-07-13 10:00UTC.

Cheers

 Stefan

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




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



Re: [VOTE] Release Ant 1.9.13 based on RC1

2018-07-11 Thread Jaikiran Pai

+1

- Downloaded .tar.gz from 
https://dist.apache.org/repos/dist/dev/ant/binaries/


- Extracted locally, checked WHATSNEW, NOTICE files.

- Browsed some random manual pages. Looks fine.

- Built some internal Ant based projects. All went fine.

- Tested that the following build script works with this new version 
(and fails with previous 1.9.x released version) to verify the 
https://bz.apache.org/bugzilla/show_bug.cgi?id=62164 issue:



    
        src="http://downloads.sourceforge.net/easymock/easymock-3.2.zip; 
dest="${basedir}/downloaded/"/>

    


-Jaikiran



On 10/07/18 3:26 PM, Stefan Bodewig wrote:

Hi all

I've created a new release candidate for 1.9.13 with a few bug fixes.

git tag: ANT_1.9.13_RC1
  on commit: e7a4d8683
tarballs: https://dist.apache.org/repos/dist/dev/ant/
  revision: 28014
Maven artifacts:
  
https://repository.apache.org/content/repositories/orgapacheant-1034/org/apache/ant/

This Vote will be open at least for 72 hours and close no earlier than
2018-07-13 10:00UTC.

Cheers

 Stefan

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




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



Re: ant git commit: Unbreak tests

2018-07-07 Thread Jaikiran Pai

Hello Martijn,

Thank you for spending time on this and for that checker. I did look 
into yourmail and considered itbefore deciding on what to do with the 
state of upstream branches.I decided to go with a complete revert 
approach (which I explain in a separate reply in this thread), because I 
personally felt a lot more confident in what it meant and involved, in 
terms of git technicalities.
Again, thank you very much for these efforts. Just like you and everyone 
else who's been involved in the project, I am not happy that we had to 
do a revertand the sequence of eventswhich led us to this.


-Jaikiran



On 06/07/18 5:19 PM, j...@apache.org wrote:

Hello all

Just for your info, please take into consideration for a rollback or 
not descision (I am neither happy with the commit, nor happy with a 
rollback and therefore am 0 on rollback or not):



I have written a small checker to remove all whitespace only diffs 
from the diffs on the URL below.


Significant whitespace changes that may have been lost would be 
unlikely (space difference before "/>" , ">" or ")" and around "=" is 
also ignored)


That would reduce the original "2f64e0b5"  diff to (the extra lines 
starting with \ before the diff are added by the checker i wrote)


Removing whitespace only changes from asf.txt
From: Gintas Grigelionis 
Date: Sun, 1 Jul 2018 13:31:35 + (+0200)
Subject: Trailing whitespace
X-Git-Url: 
https://git1-us-west.apache.org/repos/asf?p=ant.git;a=commitdiff_plain;h=2f64e0b5


Trailing whitespace
---

\
\@ -87,11 +87,11 @@  
  JDepend Analysis align="right">Designed for use with href="http://www.clarkware.com/software/JDepend.html;>JDepend and 
https://ant.apache.org;>Ant.  width="100%"> Summary 

\@ -87,11 +87,11 @@  
  JDepend Analysis align="right">Designed for use with href="http://www.clarkware.com/software/JDepend.html;>JDepend and 
http://jakarta.apache.org;>Ant.  width="100%"> Summary 


\
diff --git a/src/etc/jdepend.xsl b/src/etc/jdepend.xsl
index f813297..907ade2 100644
--- a/src/etc/jdepend.xsl
+++ b/src/etc/jdepend.xsl
@@ -87,11 +87,11 @@
 
 
 
-
+
 JDepend Analysis
-    Designed for use with href="http://www.clarkware.com/software/JDepend.html;>JDepend and 
http://jakarta.apache.org;>Ant.

-    
-
+    Designed for use with href="http://www.clarkware.com/software/JDepend.html;>JDepend and 
https://ant.apache.org;>Ant.

+    
+
 
 Summary
 
\
\@ -57,8 +57,8 @@  dir="${test.dir}/src/org/apache/tools/ant"/> dir="${test.dir}/dest"/> file="${test.dir}/src/org/apache/tools/ant/DirscannerSetup.java"> 

Re: ant git commit: Unbreak tests

2018-07-07 Thread Jaikiran Pai
ream repo.


At this point, these branches are in a state where they can be used for 
regular development and other planned activities.


-Jaikiran

On 06/07/18 2:32 PM, Stefan Bodewig wrote:

On 2018-07-06, Jaikiran Pai wrote:

On 05/07/18 2:42 PM, Stefan Bodewig wrote:
On 2018-07-05, Jaikiran Pai wrote: 
I personally believe that reviewing these meaningless changes is a 
waste of time and energy. I'm in favour of rolling back the entire 
commit set if that's what it takes. 
+1 
although reverting the commits in both branches and merging back the 
1.9.x branch is likely going to end in an ugly merge that will need 
review as well. Hopefullly a shorter one. 
Yes, I agree.I plan to attempt this later tonight (around 8 hours 
from now) if no one else gets to it before that. Just letting it know 
here, so that we don't end up duplicating these efforts. 
Thank you. I'm unlikely to get there before you do, would have tackled 
it tomorrow. Stefan 
- 
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional 
commands, e-mail: dev-h...@ant.apache.org



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



Re: ant git commit: Unbreak tests

2018-07-06 Thread Jaikiran Pai



On 05/07/18 2:42 PM, Stefan Bodewig wrote:

On 2018-07-05, Jaikiran Pai wrote:


I personally believe that reviewing these meaningless changes is a
waste of time and energy. I'm in favour of rolling back the entire
commit set if that's what it takes.

+1

although reverting the commits in both branches and merging back the
1.9.x branch is likely going to end in an ugly merge that will need
review as well. Hopefullly a shorter one.
Yes, I agree.I plan to attempt this later tonight (around 8 hours from 
now) if no one else gets to it before that. Just letting it know here, 
so that we don't end up duplicating these efforts.


-Jaikiran

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



Re: ant git commit: Enhance the Java task to allow single file source program execution, a feature, introduced in Java 11

2018-07-05 Thread Jaikiran Pai

On 05/07/18 1:02 AM, Stefan Bodewig wrote:

On 2018-07-04,  wrote:


Enhance the Java task to allow single file source program execution, a
feature, introduced in Java 11

+1

Could you please add javadocs to the new getter/setter in
CommmandLineJava?

Ah yes, missed that one. Added now.

-Jaikiran

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



Re: ant git commit: Unbreak tests

2018-07-04 Thread Jaikiran Pai

On 05/07/18 12:57 AM, Stefan Bodewig wrote:

Gintas,


-  passfile="testpassfile.tmp"%/>
+  passfile="testpassfile.tmp"/>

the commit that introduced the issue was labeled "Trailing whitespace"
and I trusted to contain exactly that and didn't bother reviewing
it. Obviously it did not.

A single commit that spans a dozen mail messages is something you really
cannot review properly.

Glitches happen, this is not a problem. But if they hide inside a patch
that contains more than 4500 changes lines it becomes impossible to deal
with them.

Given we were planning to cut new releases I now feel very uncomfortable
and compelled to wade through all those 4500 lines as well as the 4500
lines of the other commit with the same message and the merge of the 1.9
branch (and doing the same to the equally big commits on the 1.9.x
branch). This is going to delay the releases by several days, at least.

It was made explicitly clear by committers, PMC members and Ant PMC 
chairman that the commits of these nature aren't acceptable. Yet, more 
and more such commits have been done over and over again, using these 
upstream repos as a personal playground and forcing it on the rest of 
the community. At this point, I personally believe that reviewing these 
meaningless changes is a waste of time and energy. I'm in favour of 
rolling back the entire commit set if that's what it takes.


-Jaikiran

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



Re: Testing IvyDE

2018-07-04 Thread Jaikiran Pai



On 01/07/18 6:35 PM, Nicolas Lalevée wrote:

Le 28 juin 2018 à 08:41, Jaikiran Pai  a écrit :


On 27/06/18 10:12 PM, Nicolas Lalevée wrote:

Since there is a work around (hitting refresh after resolve) and it is an RC, 
we could ship it like that and fix it later. But due to the automatic update 
via the update site, I bet most users will update even if it is an RC. So I am 
not sure what I should vote. So I vote -0 for me for now.

I was reserving my vote just for this reason. I don't use Eclipse so I wanted 
to see if someone more familiar with it has an opinion about this bug. You are 
right that it's going to end up affecting everyone once we release this. Given 
that the purpose of this release is revive this project a bit and not break 
setups where things are working fine and the fact that this will end up being 
an annoying kind of workaround (having to hit refresh after resolve), I don't 
see rushing this release without fixing this issue serves any purpose.

So I'll vote a -1 on this now. I know we have gone through 3 voting rounds for 
this release, so thank you everyone for being patient and testing out the 
binaries. I'll file this issue in JIRA and hopefully spend some time in Eclipse 
this weekend to try and sort this out.

I have found the issue and pushed a fix.

Thank you.


I am then worried that the master is not well tested nor used after the big 
cleanups.

Yes, I agree.



So I suggest we do a little testing now of the master.

To help with that, there is a folder in the IvyDE project which contains 
projects ready to be imported into Eclipse, they are samples of many different 
configurations which should be supported

I'll test some of these out during the week.

-Jaikiran

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



Re: FileUtils.normalize/isLeadingPath have bitten me

2018-07-03 Thread Jaikiran Pai

Hi Stefan,

I did some testing manually for this new method, with both symlinks and 
non-symlinks with both the string check version and the getParent() 
version. In both of those, I couldn't get it to break in any odd ways 
(which is a good thing). It also means that my theory that the string 
comparison may not always be a best idea is just theoretical. However, I 
just feel a bit more comfortable seeing the getParent() version since 
that then removes any kind of file separator or odd backslash/frontslash 
permutations that we may not have thought of and instead leaves it to 
the JRE implementation to deal with it. Again, this is me being a bit 
paranoid than any real demoable issue with the string comparison code. 
So thank you for using the getParent() call in this implementation.


At this point, I think these commits address the issue that we sought 
out to fix. So unless someone else sees any issues, I think we can go 
ahead and do the release that you had planned for.


-Jaikiran


On 03/07/18 1:16 PM, Stefan Bodewig wrote:

On 2018-07-02, Stefan Bodewig wrote:


On 2018-07-02, Jaikiran Pai wrote:

I just checked the commits related to this and it looks mostly
correct. However, I am still not 100% sure we have covered it all with
this new method that was introduced[1] and used in the unzip
part. What I mean is, the API expectations are right. However the
implementation _might_ need a bit of rethink since it still relies on
path string comparison (checks like endsWith) instead of a getParent()
check.

I mostly kept the string comparison for performance reasons, but maybe
that point is moot and performance should not be a concern
here. Rewriting it to use getParent is no problem at all.

Done

Stefan

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




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



Re: FileUtils.normalize/isLeadingPath have bitten me

2018-07-02 Thread Jaikiran Pai

Hi Stefan,

Sorry that I couldn't get to this earlier. My plan to spend more time on 
this during the weekend didn't work out.


I just checked the commits related to this and it looks mostly correct. 
However, I am still not 100% sure we have covered it all with this new 
method that was introduced[1] and used in the unzip part. What I mean 
is, the API expectations are right. However the implementation _might_ 
need a bit of rethink since it still relies on path string comparison 
(checks like endsWith) instead of a getParent() check. My suspicion is 
all theoretical at the moment and may not even be valid. I'm going to 
build the latest changes of Ant give it a try against a bunch of my 
theoretical use cases and see if my suspicions are really valid or not.


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


-Jaikiran


On 01/07/18 2:57 PM, Stefan Bodewig wrote:

On 2018-06-28, Stefan Bodewig wrote:


On 2018-06-28, Jaikiran Pai wrote:

Which then makes me wonder - in the context of this specific
untar/expand/unzip issue, should we probably be using a different
custom very specific logic (which relies on canonical files and
getParent()) instead of a call to isLeadingPath()?

Probably. I used isLeadingPath because it has been already there - and )
simply didn't realize it wouldn't do what I expected it to.

I decided to "fix" isLeadingPath for this edge case and add a method
using canonical paths instead - and use that in unzip and friends.

Please have a look at the proposed solution, I won't close the Bugzilla
issue before we have agreed this is the proper fix.

Cheers

 Stefan

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




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



Re: FileUtils.normalize/isLeadingPath have bitten me

2018-06-28 Thread Jaikiran Pai



On 28/06/18 8:37 PM, Stefan Bodewig wrote:

On 2018-06-28, Jaikiran Pai wrote:


However, looking at the FileUtils#isLeadingPath(...) implementation, I
wonder why it even uses normalize. Given that the goal of that API (as
stated in the javadoc) is to figure out if one path leads the other,
to me that translates to being a check to see whether the "leading"
param to that method is a parent of the "path". I suppose that can be
implemented by using the java.io.File#getCanonicalFile() call on each
of the params and then doing a iterative getParent() call on the
canonical File returned for the "path" and seeing if it ends up
leading to the canonical File returned for "leading". The call to
java.io.File#getCanonicalFile() should take care of the ".", ".." and
even symbolic link reference resolutions (which I guess is a good
thing?).

I think I have written that method long ago so I should be able to
answer that. Unfortunately I'm not.

In may cases we did not want to resolve canonical paths. I think the
expectation is that for

/dir
   /dir2
   /dir3
  link -> /dir/dir2

isLeadingPath("/dir/dir3", "/dir/dir3/link") returns true which it would
not do if links have been resolved.
That's a good example and yes it would return false if we would change 
it to use canonical paths.


Which then makes me wonder - in the context of this specific 
untar/expand/unzip issue, should we probably be using a different custom 
very specific logic (which relies on canonical files and getParent()) 
instead of a call to isLeadingPath()? I don't have an answer though and 
I will have to sleep over this a bit to see if it has other implications 
and if it does indeed solve the issue at hand.


-Jaikiran

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



Re: FileUtils.normalize/isLeadingPath have bitten me

2018-06-28 Thread Jaikiran Pai
I don't have enough background on the expectations of the normalize 
method, so can't really say how it should behave. Plus, it gets used in 
relatively larger number of places as compared to isLeadingPath, so not 
too sure how it might impact other places if we do change its existing 
semantics.


However, looking at the FileUtils#isLeadingPath(...) implementation, I 
wonder why it even uses normalize. Given that the goal of that API (as 
stated in the javadoc) is to figure out if one path leads the other, to 
me that translates to being a check to see whether the "leading" param 
to that method is a parent of the "path". I suppose that can be 
implemented by using the java.io.File#getCanonicalFile() call on each of 
the params and then doing a iterative getParent() call on the canonical 
File returned for the "path" and seeing if it ends up leading to the 
canonical File returned for "leading". The call to 
java.io.File#getCanonicalFile() should take care of the ".", ".." and 
even symbolic link reference resolutions (which I guess is a good 
thing?). Do you think this has merits? Or is the expectation of the 
isLeadingPath API solely based on the names of that passed files rather 
than their actual resolved location on the filesystem? I haven't yet 
tried it out myself to have a more clearer understanding of how it will 
end up behaving in the context that we use this API.


-Jaikiran


On 28/06/18 7:17 PM, Stefan Bodewig wrote:

Hi all

while looking into https://bz.apache.org/bugzilla/show_bug.cgi?id=62502
I realized that I had a false expectation of what normalize would do in
a certain edge case.

If you feed into it a path with more "../" segments than can be
travelled up, like

FileUtils.normalize("/tmp/dest/../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../Temp/evil.txt")

it will realize it would go outside of the file system root and returns
a new File instance with the original path. I'm not sure what I had
expected (an exception maybe) but this is now what I had assumed, my
fault.

Then isLeadingPath calls normalize for both its arguments and ends up
seeing "/tmp/dest/" is a prefix of
"/tmp/dest/../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../Temp/evil.txt"
and unzip allows the file to escape.

It seems to depend on the OS what it makes of the path, on Linux I
receive an exception but apparently Windows just swallows the excess ../
segments.

I'm not 100% sure how to fix this properly.

Is normalize doing the right thing? If so, we need to fix isLeadingPath
for example by simply always returning false if either normalized path
contains "../" segments (because that means the path cannot exist on
disk at all).

Or should the behavior of normalize change? This unit test snippet

 assertEquals("will not go outside FS root (but will not throw an exception 
either)",
 new File(localize("/1/../../b")),
 FILE_UTILS.normalize(localize("/1/../../b")));

makes me think we better leave it as is as it seems to be by design (and
I just have forgotten about it).

In either case, once we agree on the fix I propose to cut new releases
immediately.

Stefan

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




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



[CANCELLED]Re: [VOTE] Release 2.3.0-rc1 of Apache IvyDE

2018-06-28 Thread Jaikiran Pai

This vote is now officially cancelledfor the reasons noted below.

-Jaikiran

On 28/06/18 12:11 PM, Jaikiran Pai wrote:


On 27/06/18 10:12 PM, Nicolas Lalevée wrote:
Since there is a work around (hitting refresh after resolve) and it 
is an RC, we could ship it like that and fix it later. But due to the 
automatic update via the update site, I bet most users will update 
even if it is an RC. So I am not sure what I should vote. So I vote 
-0 for me for now.
I was reserving my vote just for this reason. I don't use Eclipse so I 
wanted to see if someone more familiar with it has an opinion about 
this bug. You are right that it's going to end up affecting everyone 
once we release this. Given that the purpose of this release is revive 
this project a bit and not break setups where things are working fine 
and the fact that this will end up being an annoying kind of 
workaround (having to hit refresh after resolve), I don't see rushing 
this release without fixing this issue serves any purpose.


So I'll vote a -1 on this now. I know we have gone through 3 voting 
rounds for this release, so thank you everyone for being patient and 
testing out the binaries. I'll file this issue in JIRA and hopefully 
spend some time in Eclipse this weekend to try and sort this out.


-Jaikiran





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



Re: [VOTE] Release 2.3.0-rc1 of Apache IvyDE

2018-06-28 Thread Jaikiran Pai



On 27/06/18 10:12 PM, Nicolas Lalevée wrote:
Since there is a work around (hitting refresh after resolve) and it is 
an RC, we could ship it like that and fix it later. But due to the 
automatic update via the update site, I bet most users will update 
even if it is an RC. So I am not sure what I should vote. So I vote -0 
for me for now.
I was reserving my vote just for this reason. I don't use Eclipse so I 
wanted to see if someone more familiar with it has an opinion about this 
bug. You are right that it's going to end up affecting everyone once we 
release this. Given that the purpose of this release is revive this 
project a bit and not break setups where things are working fine and the 
fact that this will end up being an annoying kind of workaround (having 
to hit refresh after resolve), I don't see rushing this release without 
fixing this issue serves any purpose.


So I'll vote a -1 on this now. I know we have gone through 3 voting 
rounds for this release, so thank you everyone for being patient and 
testing out the binaries. I'll file this issue in JIRA and hopefully 
spend some time in Eclipse this weekend to try and sort this out.


-Jaikiran



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



Re: [Bug 33169] KIndly update the date feature

2018-06-27 Thread Jaikiran Pai
Just curious about our bugzilla infrastructure - do random users get to 
change the content of these bugs, even if they aren't the ones who 
reported the issue?


-Jaikiran


On 28/06/18 9:05 AM, bugzi...@apache.org wrote:

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

Ranjeet Mane  changed:

What|Removed |Added

 Summary|ClearCase update produces   |KIndly update the date
|verbose output---request|feature
|standard output suppression |
|feature |
   Component|Optional SCM tasks  |Core




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



[VOTE] Release 2.3.0-rc1 of Apache IvyDE

2018-06-24 Thread Jaikiran Pai
I'm initiating a newer vote mail for 2.3.0-rc1 release of Apache IvyDE 
project. This addresses the blocker issue that Nicolas identified, the 
last time a vote was initiated for this version.


The newly updated tag is here 
https://git-wip-us.apache.org/repos/asf?p=ant-ivyde.git;a=tag;h=refs/tags/2.3.0-rc1 
with sha1 3581a61ec159ede16005f36e58e5e258d32090fa


You can download the distribution from this URL: 
https://dist.apache.org/repos/dist/dev/ant/ivyde/2.3.0-rc1/ at rev 27709


The Eclipse p2 repository is here: 
https://dist.apache.org/repos/dist/dev/ant/ivyde/updatesite/ivyde-2.3.0.rc1-201806251008-RELEASE/ 
at rev 27707


The 2.3.0-rc1 release of IvyDE consists of the following changes:

* FIX: xml bomb in workspace causes hang in Ivy code during Search or 
Synchronize operations (https://issues.apache.org/jira/browse/IVYDE-354)
* FIX: Deadlock in classpath container 
(https://issues.apache.org/jira/browse/IVYDE-361)
* FIX: Typo in IvyResolveJob 
(https://issues.apache.org/jira/browse/IVYDE-362)
* FIX: User-selected configurations not checked in the viewer 
(https://issues.apache.org/jira/browse/IVYDE-378)
* FIX: Fix ClassCastException 
(https://issues.apache.org/jira/browse/IVYDE-386)
* FIX: Fix the issue where the IvyDE preferences couldn't be saved 
(https://issues.apache.org/jira/browse/IVYDE-388)


* NEW: Support for OSGi 'Bundle-Classpath' directive
* NEW: Basic support for the workspace resolver to find OSGi bundles 
managed by Ivy in the workspace

* NEW: Support for storing credentials securely


Do you vote for the release of these binaries?

-Jaikiran


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



Re: [VOTE] Release AntUnit 1.4 based on RC3

2018-06-24 Thread Jaikiran Pai

+1.

- Downloaded the .tar.gz binary

- Checked some of the docs/manual

- Ran a simple project using this released version

- Checked the NOTICE file

All looks fine.

-Jaikiran


On 22/06/18 11:02 AM, Stefan Bodewig wrote:

Hi all

this is the third RC for AntUnit 1.4 with the problems Gintas identified
fixed.

tag:
  
https://git-wip-us.apache.org/repos/asf?p=ant-antlibs-antunit.git;a=tag;h=fb7a42470f8a6de50686f37519e27a068c576606

tarballs:
  https://dist.apache.org/repos/dist/dev/ant/antlibs/antunit/
  svn revision 27641

Maven artifacts:
  
https://repository.apache.org/content/repositories/orgapacheant-1033/org/apache/ant/ant-antunit/1.4/

vote will be open for 72 hours and not close before 2018-06-25 05:30 UTC.

Stefan

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




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



Re: [ANN] Apache Ant 1.9.12 and 1.10.4 Released

2018-06-24 Thread Jaikiran Pai

Thank you for running this release, Stefan.

-Jaikiran


On 22/06/18 9:09 PM, Stefan Bodewig wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

The Apache Ant Team is pleased to announce the releases of Apache Ant
1.9.12 and 1.10.4.

Apache Ant is a Java library and command-line tool that helps building
software.

The Apache Ant team currently maintains two lines of development. The
1.9.x releases require Java5 at runtime and 1.10.x requires Java8 at
runtime. Both lines are based off of Ant 1.9.7 and the 1.9.x releases
are mostly bug fix releases while additional new features are developed
for 1.10.x. We recommend using 1.10.4 unless you are required to use
versions of Java prior to Java8 during the build process.

Ant 1.10.4 contains a superset of 1.9.12 - with the exception of a few
tasks and features that no longer work with Java8 anyway (like the apt
task).

Both releases are mostly bug fix releases with a few new features
being added. In both releases the untar, unjar and unzip will no
longer extract entries whose names would make the created files be
placed outside of the destination directory by default. This is based
on a recommendation by the Snyk Security Research Team.

Source and binary distributions are available for download from the
Apache Ant download site:

http://ant.apache.org/bindownload.cgi
http://ant.apache.org/srcdownload.cgi

When downloading, please verify signatures using the KEYS file available
at the above location when downloading the release.

Changes in 1.10.4 include:
==

Changes that could break older environments:
- ---

  * ,  and  will no longer extract entries whose
names would make the created files be placed outside of the
destination directory anymore by default. A new attribute
allowFilesToEscapeDest can be used to override the behavior.
Another special case is when stripAbsolutePathSpec is false (which
no longer is the default) and the entry's name starts with a
(back)slash and allowFilesToEscapeDest hasn't been specified
explicitly, in this case the file may be created outside of the
dest directory as well.
In addition stripAbsolutePathSpec is now true by default.
Based on a recommendation by the Snyk Security Research Team.

Fixed bugs:
- ---

  * Delay the class initialization of the test classes until they are
passed to JUnit. This way we can avoid that failing static initializers
from non-test classes are reported as error when the 'skipNonTests' option
is 'true'.
Bugzilla Report 60062

  * The junit task when used with includeantruntime="no" was incorrectly
printing a warning about multiple versions of ant detected in path

  *  died with a NullPointerException since Ant 1.10.2.
Bugzilla Report 62335

  * The  task would fail with
"java.lang.ClassFormatError: Invalid Constant Pool entry Type 19" while
parsing a module-info.class. The task is compatible with
Java bytecode version 53 now.
Bug reported by Simon IJskes 
https://issues.apache.org/jira/browse/NETBEANS-781

  * Default and SecureInputHandler will now raise an error when then
end of the input stream (usually System.in or System.console) are
reached before a valid input has been read.

  * junitreport does not list testsuites that fail to start any tests
because of an exception inside the all-tests and alltests-errors frames.
Bugzilla Report 62443

Other changes:
- --

  * AntAssert is deprecated, assertThat from JUnit 4.4+, Hamcrest matchers 
and/or
ExpectedException rule provide equivalent functionality

  * PumpStreamHandler now explicitly verifies the streams for output
and error are not null and will throw an exception if they
are. This way creating a PumpStreamHandler will fail early as
opposed to some obscure errors later when closing streams or
finishing threads might fail.
Bugzilla Report 62148

  *  has a new attribute runtime which can be used to set
properties with values taken as snapshots from the
availableProcessors, freeMemory, maxMemory and totalMemory methods
of the Java Runtime class.

  * linecontains filter now has a new "matchAny" attribute which when
set to "true" allows any (instead of all) of the user-specified
strings to be present in the line.
Bugzilla Report 62313

  *  has a new basedir attribute that can be used to
resolve relative names and provides a root for the FileResources
generated.
Bugzilla Report 62379

  * The  and  nested elements of
 and  now support an encoding attribute that
can be used to specify the file's encoding.
Bugzilla Report 62379

  * New file selectors, posixGroup and posixPermissions, are available.
The new selectors and related ownedBy selector have "followSymlinks"
attribute that defaults to "true" for consistency.
Bugzilla Report 22370

  * The junitlauncher task now has a 

Re: [VOTE] Release Ant 1.10.4 based on RC1

2018-06-22 Thread Jaikiran Pai

+1.

- Downloaded the .tar.gz binary

- Checked some docs in the manual

- Used this new version to run builds against existing internal Ant 
projects.


All went fine.

-Jaikiran


On 19/06/18 12:38 PM, Stefan Bodewig wrote:

Hi all

I've created a new release candidate for 1.10.4 with a bunch of bug
fixes and the "ZipSlip" adjustment.

git tag: ANT_1.10.4_RC1
  on commit: 9dc3e788b
tarballs: https://dist.apache.org/repos/dist/dev/ant/
  revision: 27553
Maven artifacts:
  
https://repository.apache.org/content/repositories/orgapacheant-1031/org/apache/ant/

This Vote will be open at least for 72 hours and close no earlier than
2018-06-22 08:30UTC.

Cheers

 Stefan

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




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



Re: [CANCELLED] Release AntUnit 1.4 Based on RC2

2018-06-21 Thread Jaikiran Pai
I think moving to Ant 1.8.x would be a better option, given the 
relatively low chances of it causing any issues.


-Jaikiran


On 21/06/18 2:47 PM, Stefan Bodewig wrote:

On 2018-06-21, Gintautas Grigelionis wrote:


POM template has inconsistent Ant versions, 1.7.1 in compile scope and
1.8.1 in provided scope.

True.

This happened in c3f8655 which updated the dependencies to 1.8.1 because
one of the unit tests used a method of ant-testutil that hasn't been
present in Ant 1.7.

We could fix the test or explicitly document Ant 1.8.x as new
requirement - which really doesn't exist except for the tests.

The upgrade would be a breaking change but I don't expect it would break
anything in real life. Some of the other antlibs may require Ant 1.7 but
the only other one I'd expect to get new releases (Compress) is at 1.8
already, so upgrading the dependency probably doesn't do any harm to
them.

Any opinions?

Stefan

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




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



Re: [VOTE] Release Ant 1.9.12 based on RC1

2018-06-19 Thread Jaikiran Pai

+1.

- Downloaded the .tar.gz binary

- Installed locally, checked the NOTICE and some tasks' manuals. Look fine.

- Built some random existing Ant based projects using this new version. 
All went fine.


-Jaikiran


On 19/06/18 12:38 PM, Stefan Bodewig wrote:

Hi all

I've created a new release candidate for 1.9.12 with a bunch of bug
fixes and the "ZipSlip" adjustment.

git tag: ANT_1_9_12_RC1
  on commit: 6e694d820
tarballs: https://dist.apache.org/repos/dist/dev/ant/
  revision: 27552
Maven artifacts:
  
https://repository.apache.org/content/repositories/orgapacheant-1030/org/apache/ant/

This Vote will be open at least for 72 hours and close no earlier than
2018-06-22 08:30UTC.

Cheers

 Stefan

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




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



Re: .git(modules|attributes|ignore) files in source dists?

2018-06-19 Thread Jaikiran Pai
I don't have a preference on whether or not to include the SCM related 
files, but at least in the recent IvyDE release process, I setup the 
build to use "git archive" command to generate these source tar/zip 
packages[1]. The documentation of git archive doesn't explicitly state 
anything about files like .gitignore being packaged into the archive. So 
I looked into the generated source tar and those are indeed present.


I actually can't think of a reason why we should exclude these files.

[1] https://github.com/apache/ant-ivyde/blob/master/build.xml

-Jaikiran


On 19/06/18 8:12 PM, Stefan Bodewig wrote:

Hi all

when I set up the build for AntUnit I realized the source tarball didn't
contain the git config files that are part of the source repo and
changed the antlibs-common module to include them (they are part of
Ant's defaultexcludes for DirectoryScanner).

Later it dawned on me this may not be a good idea as we don't include
anything else that is SCM related either, so maybe not including the
files has been the correct choice all along.

Any opinions on whether we should include or exclude them?

Stefan

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




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



Re: [VOTE] Release AntUnit 1.4 Based on RC1

2018-06-19 Thread Jaikiran Pai

- Downloaded the tarballs (both source and binaries). Installed locally.

- Verified the checksum file. All fine.

- Ran a few antunit tests via simple Ant build files. All fine.

This all looked fine. There are some minor issues though:

1. The NOTICE file copyright year is 2005-2014

2. The docs/index.html points to an incorrect location for source code:

The source code for the library lives in the
    ant-antlibs-antunit git repository - http://svn.apache.org/viewcvs.cgi/ant/antlibs/antunit/trunk/;>https://git-wip-us.apache.org/repos/asf/ant-antlibs-antunit.git.

The text of that link has the right location, however the actual href 
points to the SVN repo.


3. The docs/assert.html has a typo in its example:




  

  

The closing assertTrue tag is malformed. This specific typo isn't a blocker IMO,
for the release. Neither do I consider the index.html repo link typo to be a 
blocker.

I don't know if the copyright year issue should warrant a new vote. If it 
doesn't, then it's a +1 for this release from me.

-Jaikiran




On 19/06/18 1:27 AM, Stefan Bodewig wrote:

On 2018-06-18, Stefan Bodewig wrote:


Hi all
there haven't been big changes but the race condition has been nagging
us, so I've prepared artifacts to release them as AntUnit 1.4.
tag:
  
https://git-wip-us.apache.org/repos/asf?p=ant-antlibs-antunit.git;a=tag;h=c4af2e6f2ff632b896a15e7611e01b36bf4eada9
tarballs:
  https://dist.apache.org/repos/dist/dev/ant/antlibs/antunit/
  svn revision 27536
Maven artifacts:
  
https://git-wip-us.apache.org/repos/asf?p=ant-antlibs-antunit.git;a=tag;h=c4af2e6f2ff632b896a15e7611e01b36bf4eada9

sorry, Maven artifacts:

https://repository.apache.org/content/repositories/orgapacheant-1029/org/apache/ant/ant-antunit/1.4/


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




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



[CANCEL] [VOTE] Apache IvyDE 2.3.0-rc1 release

2018-06-18 Thread Jaikiran Pai

Given the nature of this issue, I'm cancelling this vote.

A new one will be initiated this week.

-Jaikiran


On 19/06/18 5:05 AM, Jaikiran Pai wrote:
Thanks for testing this Nicolas. This indeed is a big enough issue to 
be considered a blocker. I'll take a look at this.


I'll also include the sha and rev in a newer vote and update our 
release instructions.


-Jaikiran
On Tuesday, June 19, 2018, Nicolas Lalevée <mailto:nicolas.lale...@hibnet.org>> wrote:

> First, thank you very much Jaikiran to make this release happen.
>
> So checksum, signatures, installation, build, resolve on projects 
went well. But I have found a regression: global preferences cannot be 
saved anymore.
> cf https://issues.apache.org/jira/browse/IVYDE-388 
<https://issues.apache.org/jira/browse/IVYDE-388>

>
> Looking at the code, indeed it cannot work.
> 
https://github.com/apache/ant-ivyde/blob/c92ed1b9247642dfaa67e5cf84528cfa20931c47/org.apache.ivyde.eclipse/src/java/org/apache/ivyde/internal/eclipse/ui/preferences/PreferenceConstants.java#L136 
<https://github.com/apache/ant-ivyde/blob/c92ed1b9247642dfaa67e5cf84528cfa20931c47/org.apache.ivyde.eclipse/src/java/org/apache/ivyde/internal/eclipse/ui/preferences/PreferenceConstants.java#L136>

>
> I think it deserves to be fixed before being consumed by end users.
> So -1 for me.
>
> Also, it will be better to mention the sha1 of the git tag and the 
svn revision of the artifact in dist. We should update the release 
instructions to not forgot it, like I have done for the last release 
of Ivy:
> 
https://github.com/apache/ant-ivy/blob/master/asciidoc/dev/makerelease.adoc#11-call-for-a-vote-to-approve-the-release 
<https://github.com/apache/ant-ivy/blob/master/asciidoc/dev/makerelease.adoc#11-call-for-a-vote-to-approve-the-release>

>
> Nicolas
>
>> Le 17 juin 2018 à 08:45, Jaikiran Pai <mailto:jai.forums2...@gmail.com>> a écrit :

>>
>> This is a newer vote mail that I'm initiating for the 2.3.0-rc1 
release of IvyDE.

>>
>> The newly updated tag is here 
https://git1-us-west.apache.org/repos/asf?p=ant-ivyde.git;a=commit;h=refs/tags/2.3.0-rc1

>>
>> You can download the distribution from this URL: 
https://dist.apache.org/repos/dist/dev/ant/ivyde/2.3.0-rc1/

>>
>> The Eclipse p2 repository is here: 
https://dist.apache.org/repos/dist/dev/ant/ivyde/updatesite/ivyde-2.3.0.rc1-201806171016-RELEASE/

>>
>> The 2.3.0-rc1 release of IvyDE consists of the following changes:
>>
>> * FIX: xml bomb in workspace causes hang in Ivy code during Search 
or Synchronize operations 
(https://issues.apache.org/jira/browse/IVYDE-354)
>> * FIX: Deadlock in classpath container 
(https://issues.apache.org/jira/browse/IVYDE-361)
>> * FIX: Typo in IvyResolveJob 
(https://issues.apache.org/jira/browse/IVYDE-362)
>> * FIX: User-selected configurations not checked in the viewer 
(https://issues.apache.org/jira/browse/IVYDE-378)
>> * FIX: Fix ClassCastException 
(https://issues.apache.org/jira/browse/IVYDE-386)

>>
>> * NEW: Support for OSGi 'Bundle-Classpath' directive
>> * NEW: Basic support for the workspace resolver to find OSGi 
bundles managed by Ivy in the workspace

>> * NEW: Support for storing credentials securely
>>
>>
>> Do you vote for the release of these binaries?
>>
>>
>> -Jaikiran
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org 
<mailto:dev-unsubscr...@ant.apache.org>
>> For additional commands, e-mail: dev-h...@ant.apache.org 
<mailto:dev-h...@ant.apache.org>

>>
>
> 




  1   2   3   >