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: 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 Vaiciukevičius)
>>> @@ -181,7 +182,6 @@ Here is the list of people who have contributed
>> source code and documentation up
>>>   * Tobias Himstedt
>>>   * Achim Huegen
>>>   * Pierre Hägnestrand
>>> -* 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: 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 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 +-
>>>> ...

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: 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&countryCode=&timeZone=0&format=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&countryCode=&timeZone=0&format=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: 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: 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: 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: 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: [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-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: [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



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



[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: [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



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: [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



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



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



[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



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



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: 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: 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: 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: 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: 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: [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.
>>> packages="com.dummy.test.b*:com.dummy.test.c*"/>
>>> href="https://docs.oracle.com/javase/8/docs/api/"; 
>> packagelistLoc="C:\tmp"/>
>>;
>> -
>> +
>>
>>  is the same as
>>
>> @@ -894,7 +894,7 @@ See Command line 
>> arguments.
>>> packages="com.dummy.test.b*:com.dummy.test.c*"/>
>>> href="https://docs.oracle.com/javase/8/docs/api/"; 
>> packagelistLoc="C:\tmp"/>
>>;
>> -
>> +
>>
>>  or
>>
>> @@ -917,7 +917,7 @@ See Command line 
>> arguments.
>>> packages="com.dummy.test.b*:com.dummy.test.c*"/>
>>> href="https://docs.oracle.com/javase/8/docs/api/"; 
>> packagelistLoc="C:\tmp"/>
>>;
>> -
>> +
>>
>>  
>>  
>> 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));
>>  }
>>]]>
>> -
>> +
>>
>>  
>>
>> diff --git a/manual/Tasks/serverdeploy.html b/manual/Tasks/serverdeploy.html
>> index

[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: [VOTE] Release Ant 1.9.14 based on RC1

2019-03-14 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



Re: [VOTE] Release Ant 1.9.14 based on RC1

2019-03-14 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



[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



[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  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  elements for
   command line arguments that are not supported explicitly by the
   tasks via attributes.

 * added several attributes to  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


[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



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



[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



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



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



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



[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: [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



[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



[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  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  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  elements for
   command line arguments that are not supported explicitly by the
   tasks via attributes.

 * added several attributes to  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-rele

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



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&revcount=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



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



Unintentional broken compatibility of Ant 1.10.6 with Java 8

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

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

-Jaikiran




signature.asc
Description: OpenPGP digital signature


Re: Unintentional broken compatibility of Ant 1.10.6 with Java 8

2019-05-24 Thread Jaikiran Pai


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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

-Jaikiran



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

2019-05-27 Thread Jaikiran Pai
Hi Martijn,

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

-Jaikiran

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

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



Re: Augmenting the ant wrapper script for OS packaging

2019-06-11 Thread Jaikiran Pai


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

+1.

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

-Jaikiran


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



Re: JDK 13 enters Rampdown Phase One

2019-06-20 Thread Jaikiran Pai
Hi Rory,

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

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


(Failures there are known failures).

-Jaikiran

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

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



Re: JDK 13 , JDK 14 & Valhalla Early Access builds are available.

2019-07-10 Thread Jaikiran Pai
Hi Rory,

No issues noticed with these 13 and 14 versions against a Linux CI job
https://builds.apache.org/job/Ant%20Master%20(latest%20EA%20JDK)/18/

-Jaikiran

On 08/07/19 6:16 PM, Rory O'Donnell wrote:
>  Hi Stefan/Jaikiran,
>
> **OpenJDK* 13 Early Access build **28 is now available **at : -
> 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 28 [1]
>
>
> *Reminder of a change in b24 - A jrt URI can only encode paths to
> files in /modules tree **(JDK-8224946
> )*
>
> A |jrt| URL is a hierarchical URI with syntax
> |jrt:/[$MODULE[/$PATH]]|. When using the |jrt| file system, a
> |java.net.URI| object can be created with the
> |java.nio.file.Path::toUri| method to encode a normalized path to a
> file in the |/modules| tree. A |jrt| URL cannot encode a path to a
> file in the |/packages| tree. The |jrt| file system provider has
> changed in this release so that |toUri| fails with |IOError| when it
> is not possible to encode the file path as a jrt URI. *This change may
> impact tools have been making use of URLs that are not compliant with
> the syntax. Tools with paths to files in **|/packages|**can use the
> **|toRealPath()|**method to obtain the real path (in **|/modules|**)
> before attempting to convert the file path to a URI.*
>
> *OpenJDK 14 **Early Access build 4 **is now available **at : -
> jdk.java.net/14/*
>
>  * These early-access, open-source builds are provided under the GNU
>    General Public License, version 2, with the Classpath Exception
>    .
>  * Changes in this build [2]
>
>
> *Project Valhalla "L-World Inline Types" Early-Access Builds*
>
>  * Build jdk-14-valhalla+1-8
>  * These early-access builds are provided under the GNU General Public
>    License, version 2, with the Classpath Exception
>    .
>  * Please send feedback via e-mail to valhalla-...@openjdk.java.net
>    . To send e-mail to this
>    address you must first subscribe to the mailing list.
>
>
> *The Skara tooling is now open source *[3]
> we are happy to announce that the tooling for project Skara is now
> open source and available at
>
>  * https://github.com/openjdk/skara 
>
> The Skara tooling includes both server-side tools (so called "bots")
> as well as several command-line tools **
> If you have any questions, feedback etc. send them to Skara mailing
> list [4]
>
> Rgds, Rory
>
>
> [1] JDK 13 - Changes in b28 here
> 
> [2] JDK 14 - Changes in b4 here
> 
> [3]
> https://mail.openjdk.java.net/pipermail/skara-dev/2019-June/47.html
> [4] https://mail.openjdk.java.net/mailman/listinfo/skara-dev
>

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



Re: JDK 13 enters Rampdown Phase Two

2019-07-28 Thread Jaikiran Pai
Hello Rory,

I'm a bit late to this, but I just ran our Ant project tests against JDK
13 EA build 31 (the latest) and JDK 14 EA build 7 (the latest) on our
Linux CI setups and both[1][2] of them went through fine without any
unexpected failures.

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

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

-Jaikiran

On 22/07/19 3:26 PM, Rory O'Donnell wrote:
> Hi Stefan/Jaikiran,
>
> Any issues to report on JDK 13 , would like to hear the status as we
> are now in rampdown phase 2 ?
>
> **OpenJDK builds *- JDK 13 Early Access build 30 **is now available
> **at : - jdk.java.net/13/*
>
>  * Per the JDK 13 schedule [1], we are now in Rampdown Phase Two.
>  o For more details , see Mark Reinhold's email to jdk-dev mailing
>    list [2]
>  o The overall feature set is frozen, no further JEPs will be
>    targeted to this release.
>  o Per the JDK Release Process [3] we now turn our focus to P1 and
>    P2 bugs.
>
>  * I want to draw your attention to some noteable changes in previous
>    builds of JDK 13. These changes  are important for those that
>    develop/maintain their own socket implementation
>    (java.net.SocketImpl) or use the setSocketImplFactory or
>    setSocketFactory APIs to change the system-wide socket implementation:
>
>  o http://jdk.java.net/13/release-notes#JDK-8224477 - delivered in
>    build 23
>  o http://jdk.java.net/13/release-notes#JDK-8216978 - delivered in
>    build 20
>  o http://jdk.java.net/13/release-notes#JDK-8220493 - delivered in
>    build 13
>
> **OpenJDK builds *- JDK 14 Early Access build 6 is **now available
> **at : - jdk.java.net/14/*
>
>  * These early-access, open-source builds are provided under the
>  o GNU General Public License, version 2, with the Classpath
>    Exception .
>  * Changes of interest since last email
>  o 8225239: Refactor NetworkInterface lookups
>  o 8226409: Enable argument profiling for sun.misc.Unsafe.put*/get*
>  * JEP targeted to JDK 14:
>  o JEP352: Non-Volatile Mapped
>  * Bug fixes reported by Open Source Projects  :
>  o JDK-8227080 - fixed in b5 -reported by Eclipse Jetty
>
> The Java Crypto Roadmap
>  has been updated :
>
>  * Released - 16-July-2019 - Release Affected JDK 7u231 - Disabled
>    Kerberos DES encryption by default
>  * Targeted Date - 2020 - Targeted Release - JDK 8 - Transport Layer
>    Security (TLS) 1.3
>
> Rgds,Rory
>
> [1] http://openjdk.java.net/projects/jdk/13/#Schedule
> [2] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-July/003170.html
>
>

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



Re: JDK 13 is now in the Release Candidate Phase

2019-08-18 Thread Jaikiran Pai
Hello Rory,

No issues noticed with this JDK 13 build 33 and JDK 14 build
14-ea+10-332 against our Ant project on Linux CI jobs.

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

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

-Jaikiran

On 10/08/19 3:46 PM, Rory O'Donnell wrote:
> Hi Stefan/Jaikiran,
>
> *JDK 13 is now in the Release Candidate Phase - if you are aware of
> any issues, please let us know.
> *
>
> Per the JDK 13 schedule [1], we are now in the Release Candidate phase.
> The stabilization repository, jdk/jdk13, is open for P1 bug fixes per
> the JDK Release Process (JEP 3) [2].
> All changes require approval via the Fix-Request Process [3].
>
> For more details, see Mark Reinhold's email to jdk-dev mailing list [4]
>
>  * Milestone Schedule:
>  o Initial RC Build 33 - Aug 9, 2019
>  o GAC - Aug 22, 2019
>  o GAR - Sept 5, 2019
>  o GA - Sept 17, 2019
>
> *OpenJDK 13 build 33 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
>    .
>  * Schedule, status & features
>  o http://openjdk.java.net/projects/jdk/13/
>  * Release Notes
>  o http://jdk.java.net/13/release-notes
>  * Bug fixes reported by Open Source Projects  :
>  o JDK-8228764 - fixed in b32 -reported by Apache Tomcat
>
> **OpenJDK 14 *EA build 9 is now available at **http://jdk.java.net/14**
> *
>
>  * These early access, open source builds are provided under the GNU
>    General Public License, version 2, with the Classpath Exception
>    .
>  * Release Notes
>  o http://jdk.java.net/14/release-notes
>  * JEPs targeted to JDK 14
>  o JEP 352  - Non-Volatile Mapped
>    Byte Buffers
>  * Changes in this build
>   
> 
>  * Bug fixes reported by Open Source Projects  :
>  o JDK-8227170 - fixed in b8 -reported by Apache Ant
>  o JDK-8228485 - fixed in b8 -reported by JaCoCo
>  o JDK-8222791 - fixed in b7 -reported by Apache Lucene
>
> *Project Panama Early-Access Builds*
>
>  * Build jdk-14-panama+1-15 (2019/8/8) is available at
>    http://jdk.java.net/panama/
>  * These early-access, open-source builds are provided under the GNU
>    General Public License, version 2, with the Classpath Exception
>    .
>
> Regards,
> Rory
>
> [1] https://openjdk.java.net/projects/jdk/13/#Schedule
> [2] https://openjdk.java.net/jeps/3
> [3] https://openjdk.java.net/jeps/3#Fix-Request-Process
> [4]
> https://mail.openjdk.java.net/pipermail/jdk-dev/2019-August/003250.html
>

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



(source/target/release) argument passing to javac task is broken in master

2019-08-25 Thread Jaikiran Pai
Hello Martijn,

I was in the process of running some tests to decide if we are in a
state to do a release of Ant project. While doing so, I ran into an
issue where our project build no longer honours the source, target and
release attributes of the javac task for versions of javac that support
it. For example when building with Java 11 our "compile" target in
build.xml although has the correct attribute values, those values never
get passed to the underlying javac call. As a result, the compiled
classes use an incorrect major/minor version and can no longer boot in
Java 8, when compiled from Java 11. Debugging this, I found that this
issue is a consequence of the changes in [1][2][3]. [2] and [3] are just
follow-up commits to [1], so the main issue seems to be related to the
change in [1]. I tried to review it, but don't have much context around
that change. Was it related to some enhancement/bug-fix? Let me know if
you need a simple reproducer to help reproduce this problem locally.

I haven't yet had a chance to see if this impacts other attributes of
the javac task and not just source/target/release attributes.

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

[2]
https://github.com/apache/ant/commit/7b825e7c9600aa98156572bf8e83871f7e6bd911

[3]
https://github.com/apache/ant/commit/4af231688855cfc59c11e24250852158b3eeb3f8

-Jaikiran




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



Re: (source/target/release) argument passing to javac task is broken in master

2019-08-25 Thread Jaikiran Pai
Hi Martijn,

I've sent the reproducer in a private mail. I am not expecting a fix
today and neither do I plan to release immediately, so please take your
time to look into this - there's no rush.

-Jaikiran

On 25/08/19 1:10 PM, j...@apach.org wrote:
> Hi Jaikiran
> 
> Will look into it immediately, if you have a simple reproducer it would
> be great if you could mail it to me.
> 
> The problem that was hit was that JAVA10 and higher were becoming
> ambiguous with JAVA 1.0, furthermore I removed code that would only be
> triggered if run on version below java 8.
> 
> Br Martijn
> 
> 
> On 25-08-19 09:18, Jaikiran Pai wrote:
>> Hello Martijn,
>>
>> I was in the process of running some tests to decide if we are in a
>> state to do a release of Ant project. While doing so, I ran into an
>> issue where our project build no longer honours the source, target and
>> release attributes of the javac task for versions of javac that support
>> it. For example when building with Java 11 our "compile" target in
>> build.xml although has the correct attribute values, those values never
>> get passed to the underlying javac call. As a result, the compiled
>> classes use an incorrect major/minor version and can no longer boot in
>> Java 8, when compiled from Java 11. Debugging this, I found that this
>> issue is a consequence of the changes in [1][2][3]. [2] and [3] are just
>> follow-up commits to [1], so the main issue seems to be related to the
>> change in [1]. I tried to review it, but don't have much context around
>> that change. Was it related to some enhancement/bug-fix? Let me know if
>> you need a simple reproducer to help reproduce this problem locally.
>>
>> I haven't yet had a chance to see if this impacts other attributes of
>> the javac task and not just source/target/release attributes.
>>
>> [1]
>> https://github.com/apache/ant/commit/8f903513877e81e1c2e180c80c467f1ad71fc1d9
>>
>>
>> [2]
>> https://github.com/apache/ant/commit/7b825e7c9600aa98156572bf8e83871f7e6bd911
>>
>>
>> [3]
>> https://github.com/apache/ant/commit/4af231688855cfc59c11e24250852158b3eeb3f8
>>
>>
>> -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: Fixed regression on javac version selection in case build.compiler property is set.

2019-08-25 Thread Jaikiran Pai
Thank you Martijn, your commit does indeed fixes the issues I was
running into.

On 25/08/19 3:18 PM, Martijn Kruithof wrote:
> This still leaves an issue,
>
> If ant is run using java 8 and an external compiler java 11 is used,
> the correct compiler version is not determined, this is also the case
> in the ant 1.10.6 release.

Do you mean using the "executable" attribute of the javac task to point
to an external compiler?

-Jaikiran


>
> On 25-08-19 11:44, j...@apache.org wrote:
>> This is an automated email from the ASF dual-hosted git repository.
>>
>> jkf pushed a commit to branch master
>> in repository https://gitbox.apache.org/repos/asf/ant.git
>>
>>
>> The following commit(s) were added to refs/heads/master by this push:
>>   new aac25de  Fixed regression on javac version selection in
>> case build.compiler property is set.
>>   new 5387d84  Merge branch 'master' of
>> https://gitbox.apache.org/repos/asf/ant
>> aac25de is described below
>>
>> commit aac25de91c3301f445445dea835cdfe5f9121891
>> Author: jkf 
>> AuthorDate: Sun Aug 25 11:42:58 2019 +0200
>>
>>  Fixed regression on javac version selection in case
>> build.compiler property is set.
>> ---
>>   .../taskdefs/compilers/DefaultCompilerAdapter.java | 22
>> +++---
>>   1 file changed, 15 insertions(+), 7 deletions(-)
>>
>> diff --git
>> a/src/main/org/apache/tools/ant/taskdefs/compilers/DefaultCompilerAdapter.java
>> b/src/main/org/apache/tools/ant/taskdefs/compilers/DefaultCompilerAdapter.java
>>
>> index c996e38..ec2d9d8 100644
>> ---
>> a/src/main/org/apache/tools/ant/taskdefs/compilers/DefaultCompilerAdapter.java
>> +++
>> b/src/main/org/apache/tools/ant/taskdefs/compilers/DefaultCompilerAdapter.java
>> @@ -796,8 +796,7 @@ public abstract class DefaultCompilerAdapter
>>    */
>>   @Deprecated
>>   protected boolean assumeJava9() {
>> -    return assumeJavaXY("javac1.9", JavaEnvUtils.JAVA_9)
>> -    || assumeJavaXY("javac9", JavaEnvUtils.JAVA_9);
>> +    return assumeJava9Plus() && !assumeJava10Plus();
>>   }
>>     /**
>> @@ -806,9 +805,9 @@ public abstract class DefaultCompilerAdapter
>>    * @since Ant 1.10.2
>>    */
>>   protected boolean assumeJava9Plus() {
>> -    return "javac1.9".equals(attributes.getCompilerVersion())
>> -    || "javac9".equals(attributes.getCompilerVersion())
>> -    || assumeJava10Plus();
>> +    return assumeJavaXY("javac1.9", JavaEnvUtils.JAVA_9)
>> +    || assumeJavaXY("javac9", JavaEnvUtils.JAVA_9)
>> +    || assumeJava10Plus();
>>   }
>>     /**
>> @@ -817,7 +816,11 @@ public abstract class DefaultCompilerAdapter
>>    * @since Ant 1.10.7
>>    */
>>   protected boolean assumeJava10Plus() {
>> -    return "javac10+".equals(attributes.getCompilerVersion());
>> +    return "javac10+".equals(attributes.getCompilerVersion())
>> +    ||
>> (JavaEnvUtils.isAtLeastJavaVersion(JavaEnvUtils.JAVA_10)
>> +    &&
>> ("classic".equals(attributes.getCompilerVersion())
>> +    || "modern".equals(attributes.getCompilerVersion())
>> +    ||
>> "extJavac".equals(attributes.getCompilerVersion(;
>>   }
>>     /**
>> @@ -825,7 +828,12 @@ public abstract class DefaultCompilerAdapter
>>    * @since Ant 1.8.3
>>    */
>>   private boolean assumeJavaXY(final String javacXY, final String
>> javaEnvVersionXY) {
>> -    return javacXY.equals(attributes.getCompilerVersion());
>> +    String compilerVersion = attributes.getCompilerVersion();
>> +    return javacXY.equals(compilerVersion) ||
>> +    (JavaEnvUtils.isJavaVersion(javaEnvVersionXY)
>> +    && ("classic".equals(compilerVersion)
>> +    || "modern".equals(compilerVersion)
>> +    || "extJavac".equals(compilerVersion)));
>>   }
>>     /**
>>

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



Re: JDK 13 is now in the Release Candidate Phase & JDK 14 build 11 is available.

2019-08-25 Thread Jaikiran Pai
Hello Rory,

No issues observed on our Linux setups running Ant against this JDK 13
build 13+33 and JDK 14 build 14-ea+11-371.

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

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

-Jaikiran

On 24/08/19 10:04 PM, Rory O'Donnell wrote:
> Hi Stefan/Jaikiran,
>
> *JDK 13 is now in the Release Candidate Phase
> *
>
> Per the JDK 13 schedule [1], we are now in the Release Candidate phase.
> The stabilization repository, jdk/jdk13, is open for P1 bug fixes per
> the JDK Release Process (JEP 3) [2].
> All changes require approval via the Fix-Request Process [3].
>
> For more details, see Mark Reinhold's email to jdk-dev mailing list [4]
>
>  * Milestone Schedule:
>  o GAC - Aug 22, 2019
>  o GAR - Sept 5, 2019
>  o GA - Sept 17, 2019
>
> **OpenJDK 14 *EA build 11 is now available at **http://jdk.java.net/14**
> *
>
>  * These early access, open source builds are provided under the GNU
>    General Public License, version 2, with the Classpath Exception
>    .
>  * Release Notes
>  o http://jdk.java.net/14/release-notes
>  * JEPs targeted to JDK 14
>  o JEP 352  - Non-Volatile Mapped
>    Byte Buffers
>  * Significant changes since the last availability email:
>  o Build 10
>  + 8226374: Restrict TLS signature schemes and named groups
>  + 8227439: Turn off AOT by default
>  o Build 11
>  + 8224974: Implement JEP 352
>  * Changes in this build
>   
> 
>
> *jpackage EA - **Build 1 (2019/8/20) *
>
>  * 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 1 (2019/8/20) is now available http://jdk.java.net/jpackage/
>  * Please send feedback via e-mail to core-libs-...@openjdk.java.net
>    
>
> Regards,
> Rory
>
> [1] https://openjdk.java.net/projects/jdk/13/#Schedule
> [2] https://openjdk.java.net/jeps/3
> [3] https://openjdk.java.net/jeps/3#Fix-Request-Process
> [4]
> https://mail.openjdk.java.net/pipermail/jdk-dev/2019-August/003250.html
>

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



Recent build enhancements and CI jobs to help test Java runtime compatibility

2019-08-26 Thread Jaikiran Pai
A while back I mentioned[1] the issue we ran into with our Ant 1.10.6
release which broke compatibility with Java 8 runtime. I outlined what
needed to be done to be able to catch such issues going forward. In
short, we needed our build logic and our CI infrastructure to be able to
do the following:

- Our build should use the right javac attributes to compile the right
set of classes (some of which use Java 9+ APIs)
- Our CI infrastructure should have jobs which do:
    - Build (compile, jar, binary generation) using multiple different
Java versions, including the minimal supported Java version, and then
use the same Java version which was used to build Ant, to run tests
against that built version. We already had and will continue to have
such CI jobs[2]
    - Build (compile, jar, binary generation) using multiple different
Java versions, including the minimal supported Java version and then use
the minimal support Java version (Java 8) to run (only) tests against
that built Ant. This will cover the case where Ant is built with a
higher Java version and is being run in the minimal supported Java
runtime (which right now is Java 8).

To accomplish the above goals, this weekend I have been doing some minor
enhancements to the build infrastructure and also have introduced a
test-compatibility.sh[3] script which helps us to use a CI job to run
this Java runtime compatibility tests. A new job[4] has also been
created to use this script.

When I find some time I'll replicate that script to Windows OS too and
then have a CI job for Windows use this. All this should help us be a
bit more confident about our compatibility with different Java versions.


[1] https://www.mail-archive.com/dev@ant.apache.org/msg48001.html
[2] https://builds.apache.org/job/Ant-Build-Matrix-master-Linux/ and
https://builds.apache.org/job/Ant-Build-Matrix-master-Windows/
[3] https://github.com/apache/ant/blob/master/test-compatibility.sh
[4] https://builds.apache.org/job/Ant%20Master%20Compatibility%20Linux/

-Jaikiran


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



Re: Recent build enhancements and CI jobs to help test Java runtime compatibility

2019-08-26 Thread Jaikiran Pai


On 26/08/19 5:28 PM, Jaikiran Pai wrote:
> To accomplish the above goals, this weekend I have been doing some minor
> enhancements to the build infrastructure and also have introduced a
> test-compatibility.sh[3] script which helps us to use a CI job to run
> this Java runtime compatibility tests. 
>
In this script, I use the AdoptOpenJDK Java 8 update builds from here
https://adoptopenjdk.net/index.html

-Jaikiran


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



Ant 1.10.7 release?

2019-08-27 Thread Jaikiran Pai
Now that the master branch has the necessary changes I had in mind to
fix the Java compatibility issue from reoccurring and also a few other
bug fixes, should we go ahead and release 1.10.7 of Ant?

Martijn, you did mention in a recent mail that you might be interested
in looking into a javac task issue, which happens to be present even in
1.10.6 (and perhaps previous versions too). Do you want this fix to be
part of 1.10.7, in which case we can wait for the fix (no rush).

I don't have any changes of mine that are pending. Anyone else? I also
don't plan to release a 1.9.x at this point, but if someone feels we
should release that too, I can do that too.

During this 1.10.x release we will be doing a first "snap" release of
Ant. I'll co-ordinate with Stefan during/after the release process to
release that into snapcraft.

-Jaikiran




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



RAT report for Ant and our copyright header changes

2019-08-31 Thread Jaikiran Pai
Our Ant Rat reports have been complaining[1] about "unknown" license
headers on (all) our source files. This has to do with the recent change
where we changed the reference
http://www.apache.org/licenses/LICENSE-2.0 to
https://www.apache.org/licenses/LICENSE-2.0 (http -> https). Based on a
previous discussion here[2], I believe the change that has been done in
these source files is correct and doesn't need to be reverted. I have
updated our build file to introduce a custom license matcher which
considers the current copyright header (with the https link) as valid
and approved[3]. Long term, this needs to be communicated/discussed with
the RAT project and have it enhanced there.

I will continue with the release plans that I had for today and start
the RC release of 1.10.7 for Ant. We can always veto the release if this
change isn't valid.

[1]
https://builds.apache.org/view/A/view/Ant/job/Ant_Nightly/1127/artifact/build/reports/rat/report.txt/*view*/

[2] https://www.mail-archive.com/dev@ant.apache.org/msg48007.html

[3]
https://gitbox.apache.org/repos/asf?p=ant.git;a=commitdiff;h=9c656cc1040948412db0bb0d9ed55b2d06084a34

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

2019-09-01 Thread Jaikiran Pai
Hello all,

I've created a release candidate RC1 for Ant 1.10.7 release. This
release is mostly a bug fix release with just a couple of minor
enhancements.

The release was built 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.

This is the first release where we are publishing our Ant artifact(s) as
a "snap" to https://snapcraft.io/. Details on how to access this release
candidate version of the snap is mentioned below.

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

git tag:
    ANT_1.10.7_RC1 on commit 80768efaab4003d90252095d160facfc35adc35e

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

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

Snapcraft artifact:
    Available at https://snapcraft.io/ant as version "1.10.7" under the
"latest/candidate" channel


This vote will be open for at least 72 hours and will not close before
4th September 2019 12:00 UTC.

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

2019-09-01 Thread Jaikiran Pai
+1.

- Downloaded the .tar.gz binary

- Installed it and checked the NOTICE file.

- Random check of some manuals

- Built some internal projects using this new version

- Verified that the issue noted in
https://bz.apache.org/bugzilla/show_bug.cgi?id=63457 is fixed in this
version, by running the code attached to that issue, with this newer
version.

- Verified the sha512 checksum for the -bin.tar.gz is correct.

-Jaikiran

On 01/09/19 5:40 PM, Jaikiran Pai wrote:
> Hello all,
>
> I've created a release candidate RC1 for Ant 1.10.7 release. This
> release is mostly a bug fix release with just a couple of minor
> enhancements.
>
> The release was built 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.
>
> This is the first release where we are publishing our Ant artifact(s) as
> a "snap" to https://snapcraft.io/. Details on how to access this release
> candidate version of the snap is mentioned below.
>
> Release notes:
>     https://dist.apache.org/repos/dist/dev/ant/RELEASE-NOTES-1.10.7.html
>
> git tag:
>     ANT_1.10.7_RC1 on commit 80768efaab4003d90252095d160facfc35adc35e
>
> tarballs:
>     https://dist.apache.org/repos/dist/dev/ant/
>     revision 35487
>
> Maven artifacts:
>    
> https://repository.apache.org/content/repositories/orgapacheant-1039/org/apache/ant/
>
> Snapcraft artifact:
>     Available at https://snapcraft.io/ant as version "1.10.7" under the
> "latest/candidate" channel
>
>
> This vote will be open for at least 72 hours and will not close before
> 4th September 2019 12:00 UTC.
>
> -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.10.7 based on RC1

2019-09-02 Thread Jaikiran Pai
Hi Martijn,

On 03/09/19 12:57 AM, Martijn Kruithof wrote:
>
> Please note, commit 80768efaab4003d90252095d160facfc35adc35e and the
> tag are not visible (yet)

I can see it here
https://gitbox.apache.org/repos/asf?p=ant.git;a=commit;h=80768efaab4003d90252095d160facfc35adc35e

-Jaikiran


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



[RESULT] Release Ant 1.10.7 based on RC1

2019-09-04 Thread Jaikiran Pai
With +1s from:

Martijn

Stefan

Jaikiran

and no vetos, this vote now passes.

I'll finish the rest of the release formalities soon.

Thank you both for voting.

-Jaikiran

On 03/09/19 9:57 AM, Stefan Bodewig wrote:
> On 2019-09-01, Jaikiran Pai wrote:
>
>> I've created a release candidate RC1 for Ant 1.10.7 release. This
>> release is mostly a bug fix release with just a couple of minor
>> enhancements.
>> The release was built 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.
> +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



Bugzilla release of 1.10.7 version

2019-09-04 Thread Jaikiran Pai
I am almost done with the release process, but I'll need help with
updating Bugzilla to "release" 1.10.7 and create a new 1.10.8 release,
please. Can someone with the relevant rights, please do this?

-Jaikiran


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



Re: Bugzilla release of 1.10.7 version

2019-09-04 Thread Jaikiran Pai
Thank you Stefan.

-Jaikiran

On 05/09/19 10:03 AM, Stefan Bodewig wrote:
> On 2019-09-05, Jaikiran Pai wrote:
>
>> I am almost done with the release process, but I'll need help with
>> updating Bugzilla to "release" 1.10.7 and create a new 1.10.8 release,
>> please. Can someone with the relevant rights, please do this?
> 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



Deleting older releases from svn?

2019-09-04 Thread Jaikiran Pai
One of the steps that I haven't yet done as a release manager is,
deleting the older releases from our svn repo at
dist/release/ant[binaries/sources/manual]. The release instructions say
that it's as simple as "svn rm". But before doing that I wanted to check
if I should be moving those to some "archive" location before the "svn rm"?

-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: Clarify the snapcraft release command

2019-09-05 Thread Jaikiran Pai
Hi Stefan,

On 05/09/19 12:38 PM, Stefan Bodewig wrote:
> On 2019-09-05,  wrote:
>
>> -$ snapcraft release ant REVISION latest/stable 1.10/stable
>> +$ snapcraft release ant REVISION latest/stable
>> +$ snapcraft release ant REVISION 1.10/stable
> I'm pretty sure I've done it with the single command when I published
> 1.10.6, but I may be wrong. Also the snapcraft CLI may have changed in
> between.

I think maybe they changed their CLI. When I ran the following during
the release:

snapcraft release ant 13 latest/stable 1.10/stable

I kept getting an error:

Usage: snapcraft release [OPTIONS]   
Try "snapcraft release -h" for help.

Error: Got unexpected extra argument (1.10/stable)

Splitting them up into two, worked fine.

Now that I have a few minutes, I checked their documentation (snapcraft
release -h) and that states:

"Release  on  to the selected store .
   is a comma separated list of valid channels on the store.

..."

So if I had used a comma separated list, I guess that would have worked too.

-Jaikiran



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



Re: Deleting older releases from svn?

2019-09-05 Thread Jaikiran Pai


On 05/09/19 12:36 PM, Stefan Bodewig wrote:
> On 2019-09-05, Jaikiran Pai wrote:
>
>> One of the steps that I haven't yet done as a release manager is,
>> deleting the older releases from our svn repo at
>> dist/release/ant[binaries/sources/manual]. The release instructions say
>> that it's as simple as "svn rm". But before doing that I wanted to check
>> if I should be moving those to some "archive" location before the "svn rm"?
> No, just delete them.
>
> archive.apache.org rsyncs releases and is independent of the dist svn
> repo.

Thank you Stefan. I have cleaned up 1.9.13 and 1.10.5 release artifacts
from the dist svn repo. In a few days, I will remove 1.10.6 artifacts too.

-Jaikiran


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



[ANNOUNCE] Apache Ant 1.10.7 released

2019-09-05 Thread Jaikiran Pai
The Apache Ant Team is pleased to announce the release of Apache Ant 1.10.7.

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 Java 5 at runtime and 1.10.x requires Java 8 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.7 unless you are required to use versions of
Java prior to Java 8 during the build process.

This, Ant 1.10.7 release, is mostly a bug fix release and a few minor
enhancements. This release includes a fix for a major regression in our
previous 1.10.6 release, where we unintentionally broke compatibility
with Java 8 runtime. As a result, the previous version would run into
exceptions when using Java 8 runtime, in certain tasks.

Starting this release, we now officially release to the snapcraft store
too. Details of that can be found a few lines later in this mail.

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.

People who use snapcraft for installing their tools can now install
Apache Ant from the snapcraft store at https://snapcraft.io/ant. The
"latest/stable" and "1.10/stable" channels have this 1.10.7 release
available for installation.

Changes in 1.10.7 release include:
=

Fixed bugs:
---

 * FTP still tries checking or entering directories after a timeout
   Bugzilla Report 63454

 * junitlauncher - does not detect failure in @BeforeAll
   Bugzilla Report 63479

 * Error using ant-1.10.6 with jdk8
   Bugzilla Report 63457

 * FTP task no longer duplicates a check for a file being a symlink.
   Bugzilla Report 63259

 * junitlauncher task, when used in fork mode with "",
   used to create the wrong number of listeners per test class. This
   has now been fixed.
   Bugzilla Report 63446

 * The "legacy-xml" junitlauncher task's listener would not include
   @ParameterizedTest testcases in its XML report file. This has now
   been fixed.
   Bugzilla Report 63680

Other changes:
--

 * FTP task timeout improvements.
   Bugzilla Reports 63252 and 47414

 * junitlauncher task now supports selecting test classes for execution,
   based on the JUnit 5 tags, through the new "includeTags" and
   "excludeTags" attributes.

 * prefer https over http when building ant itself, and in the ant
   documentation and sources

 * changed the references and Maven coordinates of JavaMail dependency
   to Jakarta Mail and thus javax.mail to jakarta.mail - and upgraded
   the dependency to 1.6.3.


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

- Jaikiran, on behalf of the Apache Ant community



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



Planning to initiate a Ivy release

2019-09-07 Thread Jaikiran Pai
So I finally found the time that was needed to read and understand a
part of the Ivy codebase, in order to fix the major
https://issues.apache.org/jira/browse/IVY-1580 issue. I have pushed a
commit which contains the fix as well as a testcase to reproduce and
verify the issue. Existing tests pass too.

Given that this issue has been causing problems to users who have been
using 2.5.0-rc1, I would like to go ahead and propose a new release in
the coming days for Ivy. I plan to name it 2.5.0.

This will be my first release for the Ivy project so I might take some
extra time to get it done.

Any objections to the release plan? If not, I will initiate the
formalities in the coming days.

-Jaikiran


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



Re: Planning to initiate a Ivy release

2019-09-08 Thread Jaikiran Pai


On 08/09/19 12:41 PM, Gintautas Grigelionis wrote:
> Many thanks, Jaikiran. Please consider updating JSch to 0.1.55 (fixes bugs
> with EC crypto)

Done.

>  and Commons VFS to 2.4.1 (upgrades HTTP Client to 4.5+).

We can't move to 2.4.x of Commons VFS since that requires Java 8 and Ivy
has a minimum requirement of Java 7.

> May I suggest considering preemptive authentication (aka IVY-1280) 

Like I noted in the JIRA comment[1] and even acknowledged by another
user in the PR[2], it's not yet in a state where we can confidently
introduce that enhancement. It will need a bit of research as well as
some testing to see how it behaves in the cases noted in that JIRA.
Given that it's an enhancement, I don't want it to block this release.
Having said that, I do have that JIRA (and few others) in mind, which I
plan to come back to after the release, in a subsequent version. So this
and other ideas aren't abandoned.

> and Ivy
> reports without img links to Ivy website (aka IVY-922)?

I had seen a PR for this one here[3]. Going by what the JIRA 
https://issues.apache.org/jira/browse/IVY-922 states, I would have expected any 
change related to it, to be relatively straightforward. I'm not an expert on 
image processing, but looking at that PR, I don't understand why it isn't as 
straightforward as pointing to local image resources. The PR has a big change 
(even to Java code) which seems to generate the SVG images on the fly, from 
some auto-generated code from some library. Plus there are some changes to css 
files too, which I'm not fully clear about. For this specific JIRA if the PR 
was just about using local (png) resources for the images then it would have 
been easier to review and merge it. Having said that, I don't have an objection 
on it being merged if someone else with a bit more experience with SVG, it's 
generation and usage feels this change looks good. I see Jan has already 
reviewed it. So if the current conflict being reported in that PR can be 
resolved and if Jan or others feel this is fine, I'll merge it in this release. 
Again, I don't consider this one a blocker too, so if the review and discussion 
takes time, we can always have it included in a next release. 

[1]
https://issues.apache.org/jira/browse/IVY-1280?focusedCommentId=16403338&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16403338

[2] https://github.com/apache/ant-ivy/pull/64#issuecomment-362251800

[3] https://github.com/apache/ant-ivy/pull/55

-Jaikiran



> Gintas
>
> On Sun, 8 Sep 2019 at 05:54, Jaikiran Pai  wrote:
>
>> So I finally found the time that was needed to read and understand a
>> part of the Ivy codebase, in order to fix the major
>> https://issues.apache.org/jira/browse/IVY-1580 issue. I have pushed a
>> commit which contains the fix as well as a testcase to reproduce and
>> verify the issue. Existing tests pass too.
>>
>> Given that this issue has been causing problems to users who have been
>> using 2.5.0-rc1, I would like to go ahead and propose a new release in
>> the coming days for Ivy. I plan to name it 2.5.0.
>>
>> This will be my first release for the Ivy project so I might take some
>> extra time to get it done.
>>
>> Any objections to the release plan? If not, I will initiate the
>> formalities in the coming days.
>>
>> -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: Buliding IvyDE

2019-09-13 Thread Jaikiran Pai
Tim,

I don't use Eclipse nor do I have experience building Eclipse plugins.
The IvyDE project is in maintenance mode and hasn't seen much activity.
If you are interested in helping fix some of the issues, then "master"
branch is the right branch to work against. You can raise a PR and if
it's something that I can help review and merge, I can take a look.

-Jaikiran

On 13/09/19 6:47 PM, Tim Astle wrote:
> Ah, thanks Aleksandar.
>
> Has this work started?  Just wondering what branch I should be on if I
> choose to play around.
>
> Tim
>
> On Fri, Sep 13, 2019 at 9:59 AM Aleksandar Kurtakov  
> wrote:
>> On Fri, Sep 13, 2019 at 3:55 PM Tim Astle  wrote:
>>
>>> I have the latest version of Eclipse, and unfortunately there isn't a
>>> version of IvyDE that works with it.
>>>
>>> I'm not sure if there will be a version made available, so I attempted
>>> to build it myself following this document:
>>>
>>> https://github.com/apache/ant-ivyde/blob/master/doc/src/dev/build.adoc
>>>
>>> I checked out the 2.3.0-rc1 tag (dunno, figured it's the right one)
>>> and grabbed this version of Eclipse:
>>>
>>> https://www.eclipse.org/downloads/download.php?file=/technology/epp/downloads/release/2019-06/R/eclipse-committers-2019-06-R-linux-gtk-x86_64.tar.gz&mirror_id=1249
>>>
>>> I created a local.build.properties that points to the unpacked distro
>>> above.
>>>
>>> I ran `ant install-ivy`
>>>
>>> Then when I ran `ant build`, I get the following:
>>>
>>> [pde-build]
>>> /home/tastle/Downloads/eclipse/plugins/org.eclipse.pde.build_3.10.400.v20190320-1020/scripts/genericTargets.xml:112:
>>> Processing inclusion from feature
>>> org.apache.ivyde.eclipse.resolvevisualizer.feature: Bundle
>>> org.apache.ivyde.eclipse.resolvevisualizer_2.3.0.rc1-201909130952-dev
>>> failed to resolve.:
>>> [pde-build] Missing required plug-in org.eclipse.zest.core_[1.5.0,2.0.0).
>>> [pde-build] Missing required plug-in
>>> org.eclipse.zest.layouts_[1.1.0,2.0.0).
>>> [pde-build]
>>> [pde-build]
>>> [pde-build] Total time: 1 second
>>> [pde-build] [eclipse.buildScript] Some inter-plug-in dependencies have
>>> not been satisfied.
>>> [pde-build] [eclipse.buildScript] Bundle
>>> org.apache.ivyde.eclipse.resolvevisualizer:
>>> [pde-build] [eclipse.buildScript] Missing required plug-in
>>> org.eclipse.zest.core_[1.5.0,2.0.0).
>>> [pde-build] [eclipse.buildScript] Missing required plug-in
>>> org.eclipse.zest.layouts_[1.1.0,2.0.0).
>>> [pde-build] [eclipse.buildScript] Bundle org.eclipse.epp.logging.aeri.ide:
>>> [pde-build] [eclipse.buildScript] Unsatisfied import package
>>> org.apache.lucene.document_[7.1.0,8.0.0).
>>> [pde-build] [eclipse.buildScript] Unsatisfied import package
>>> org.apache.lucene.index_[7.1.0,8.0.0).
>>> [pde-build] [eclipse.buildScript] Unsatisfied import package
>>> org.apache.lucene.search_[7.1.0,8.0.0).
>>> [pde-build] [eclipse.buildScript] Unsatisfied import package
>>> org.apache.lucene.store_[7.1.0,8.0.0).
>>> [pde-build] An error has occurred. See the log file
>>> [pde-build] /home/tastle/workspace/.metadata/.log.
>>>
>>> BUILD FAILED
>>> /home/tastle/Dev/Code/ant-ivyde/build.xml:179: Java returned: 13
>>>
>>> Did I get the wrong distribution, or are the build instructions incorrect?
>>>
>>> All I really want is IvyDE in the Eclipse Marketplace for the latest
>>> version of eclipse...
>>>
>> Eclipse IDE has been moved to use lucene 8.x thus IvyDE has to be adapted
>> too.
>>
>>
>>>
>>> Tim
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
>>> For additional commands, e-mail: dev-h...@ant.apache.org
>>>
>>>
>> --
>> Alexander Kurtakov
>> Red Hat Eclipse Team
> -
> 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: Release Announcement: General Availability of Java 13 / JDK 13

2019-09-18 Thread Jaikiran Pai
Hello Rory,

Congratulations on the GA release.

Our Ant testsuite (on Linux) against JDK 13 GA and JDK 14-ea+14-570 have
passed fine (ignore the unrelated failures)[1][2]

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

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

-Jaikiran

On 18/09/19 1:51 AM, Rory O'Donnell wrote:
>  Hi Stefan/Jaikiran,
>
> *Release Announcement: General Availability of Java 13 / JDK 13 [1] *
>
>  * JDK 13, the reference implementation of Java 13, is now Generally
>    Available.
>  * GPL-licensed OpenJDK builds from Oracle are available here:
>    https://jdk.java.net/13
>  * Release notes - https://jdk.java.net/13/release-notes
>
> This release includes the following five features:
>
>  * 350: Dynamic CDS Archives
>  * 351: ZGC: Uncommit Unused Memory
>  * 353: Reimplement the Legacy Socket API
>  * 354: Switch Expressions (Preview)
>  * 355: Text Blocks (Preview)
>
> Along with many smaller enhancements and bug fixes.
>
> Thanks to everyone who contributed JDK 13, whether by creating
> features or enhancements, logging  bugs, or downloading and testing
> the early-access builds.
>
> *JDK 14 EA build 14, under both the GPL and Oracle EA licenses, is now
> available at **http://jdk.java.net/14**.*
>
>  * JEPs targeted to JDK 14, so far
>  o 352 - Non-Volatile Mapped Byte Buffers
>    
>  * Release Notes
>  o https://jdk.java.net/14/release-notes
>  * Recent Bug fixes of Interest
>  o Build 14:
>  + 8229785: MethodType::fromMethodDescriptorString requires
>    "getClassLoader" permission
>  + 8212117: Classes are now loaded and linked by Class.forName()
>  + 8228854: Default ErrorListener No Longer Reports Warnings
>    and Errors to the Console
>  * Changes in this build
>   
> 
>    [14]
>
> *Quality Report for September 2019 is available*
>
>  *
> https://wiki.openjdk.java.net/display/quality/Quality+Outreach+report+September+2019
>
> Rgds,Rory
>
> [1]
> https://mail.openjdk.java.net/pipermail/jdk-dev/2019-September/003335.html
>

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



Re: JDK 14 - Early Access build 17 is available

2019-10-05 Thread Jaikiran Pai
Hello Rory,

No unexpected failures against our Ant project Linux OS testsuite[1].
JDK 14 build 14-ea+17-721.

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

-Jaikiran

On 04/10/19 2:42 PM, Rory O'Donnell wrote:
>  Hi Stefan/Jaikiran,
>
> *OpenJDK builds *- JDK 14 - Early Access build 17 is available at
> http://jdk.java.net/14/
>
> These early-access, open-source builds are provided under the GNU
> General Public License, version 2, with the Classpath Exception
> .
>
>  * Schedule for JDK 14
>  o 2019/12/12 Rampdown Phase One
>  o 2020/01/16 Rampdown Phase Two
>  o 2020/02/06 Initial Release Candidate
>  o 2020/02/20 Final Release Candidate
>  o 2020/03/17 General Availability
>
>  * Release notes
>  o https://jdk.java.net/14/release-notes
>
>  * JEPs targeted to JDK 14, so far
>  o 352 - Non-Volatile Mapped Byte Buffers
>    
>  o 358 - Helpful NullPointerExceptions
>    
>  * Recent Bug fixes of Interest
>  o Build 16:-
>  + JDK-8228580: DnsClient TCP socket timeout
>  + JDK-8229800: WindowsServerCore 1809 does not provide
>    d2d1.dll library required by awt.dll
>  + JDK-8230814: Enable SAX ContentHandler to handle XML
> Declaration
>  o Build 15:-
>  + JDK-8229202: Docker reporting causes secondary crashes in
>    error handling
>  + JDK-8223490: Optimize search algorithm for determining
>    default time zone
>  * Changes in this build
>   
> 
>
> *jpackage EA -* Build 14-jpackage+1-49 (2019/10/2)
>
>  * 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.
>  * These early-access builds are provided under the GNU General Public
>    License, version 2, with the Classpath Exception
>    
>  * Build 14 is now available http://jdk.java.net/jpackage/
>  * Please send feedback via e-mail to core-libs-...@openjdk.java.net
>    
>
> *
> *
>
>
>  CodeOne
>
>  * Missed some of the Core Java Platform track, see a thread of some of
>    the captured sessions: here
>    
>
>
> Rgds,Rory
>
>

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



Re: issue ivy 2.5.0 rc1

2019-10-10 Thread Jaikiran Pai
Adding to what Maarten noted - the nightly builds are available for
testing here
https://builds.apache.org/job/Ivy/lastSuccessfulBuild/artifact/build/

The plan is to release a newer version of Ivy 2.5.0 soon (one other user
has reported a different issue which I want to review first before
deciding whether or not a fix is needed for that before releasing).

-Jaikiran

On 11/10/19 12:12 AM, Maarten Coene wrote:
> Thanks for the report Patrick,
>
> it seems this issue has already been fixed in git some time ago.
> It should be available in an upcoming release or in a recent nightly build.
>
>
> Maarten
>
>
>
> Op donderdag 10 oktober 2019 20:24:50 CEST schreef ENJOLRAS Patrick 
> : 
>
>
>
>
>
>   
>
>
> Hello,
>
>  
>
> Using Ivy 2.5.0 rc1 and  2.4.0, I had very often encountered a retrieve issue 
> with the exception:  java.lang.UnsupportedOperationException…
>
>  
>
> I had debug it, it comes from 
>
> org.apache.ivy.util.FileUtil.java
>
>  
>
> 184 existingChild.remove(childDest);
>
>  
>
> To fix it
>
> Line 174 existingChild = new 
> java.util.LinkedList(Arrays.asList(children));
>
>  
>
> Encapsulate arraysList as linkedList to be able to apply remove(File) 
> function.(ArrayList fixed size cannot apply remove(File ) on it 
> =>unsupportedOperationException)
>
>  
>
>     If someone could do the modification or tell me how to submit 
> it, it will be great.
>
>  
>
> Thanks.
>
>  
>
> Regards
>
>  
>
>   
>   
>
>   
>   
> Patrick Enjolras
> DIS BPS R&D Engineer 
> Tel.: 01 55 01 59 61
>
> Gemalto is now part of the Thales Group.
> Please note that my new email address is patrick.enjol...@thalesgroup.com
>   
>  
>   
>   
>
> THALES
>
>   
> 6, rue de la Verrerie 92190 Meudon
>
>
>   
>   
> www.thalesgroup.com
>   
>   
>   
>
> 
>
> 
>
> 
>
>   
>
>   
>
>   
>
>
>  
>
>  
>
>  
>
>
>
>
> -
> 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 Ivy 2.5.0 based on RC1

2019-10-20 Thread Jaikiran Pai
Hello everyone,

I have built a candidate release for Ivy 2.5.0.

It's been a long time since we have done a release of Ivy. 2.4.0 was
released on December 26, 2014 after which it took a while to release the
next version. We revived the project a few years later and many bug
fixes and some enhancements were done. Thanks to Nicolas, 2.5.0-rc1 was
released on Apr 19, 2018. We intentionally called it 2.5.0-rc1 because
of the long delay we had between these releases and also the amount of
changes that went it. We wanted to quickly release 2.5.0 after that, but
various different reasons (some of them being newly reported bugs), it
got delayed. However, its now time to officially release 2.5.0. This is
my first release of Ivy project, so please do check out the release
artifacts and vote accordingly and if you find anything amiss, please
report. The complete set of changes that are part of this release (since
2.4.0) is listed here
https://dist.apache.org/repos/dist/dev/ant/ivy/2.5.0-site-docs/release-notes.html.

The git tag for this release is:
   
https://gitbox.apache.org/repos/asf?p=ant-ivy.git;a=tag;h=refs/tags/2.5.0_Vote_RC1
with SHA for this tag being 48234fc5ede85a865eb874a96c08472ce1751fd1

The artifacts has been published to:
    https://dist.apache.org/repos/dist/dev/ant/ivy/2.5.0/ at SVN
revision 36396

The staging Maven repository is available at:
   
https://repository.apache.org/content/repositories/orgapacheant-1043/org/apache/ivy/ivy/2.5.0/

The Eclipse updatesite is available here:
   
https://dist.apache.org/repos/dist/dev/ant/ivyde/updatesite/ivy-2.5.0.final_20191020104435/


This vote will be open for at least 72 hours and will not close before
23rd October 2019 12:00 UTC.

- Jaikiran, Ivy 2.5.0 release manager, on behalf of Ivy team


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



Re: [VOTE] Release Ivy 2.5.0 based on RC1

2019-10-21 Thread Jaikiran Pai
+1.

- Downloaded the .tar.gz and installed locally.

- Checked the NOTICE file.

- Checked some random documentation files.

- Ran some examples that are shipped.

- Built an internal project with this version.

All went fine.

-Jaikiran

On 20/10/19 4:43 PM, Jaikiran Pai wrote:
> Hello everyone,
>
> I have built a candidate release for Ivy 2.5.0.
>
> It's been a long time since we have done a release of Ivy. 2.4.0 was
> released on December 26, 2014 after which it took a while to release the
> next version. We revived the project a few years later and many bug
> fixes and some enhancements were done. Thanks to Nicolas, 2.5.0-rc1 was
> released on Apr 19, 2018. We intentionally called it 2.5.0-rc1 because
> of the long delay we had between these releases and also the amount of
> changes that went it. We wanted to quickly release 2.5.0 after that, but
> various different reasons (some of them being newly reported bugs), it
> got delayed. However, its now time to officially release 2.5.0. This is
> my first release of Ivy project, so please do check out the release
> artifacts and vote accordingly and if you find anything amiss, please
> report. The complete set of changes that are part of this release (since
> 2.4.0) is listed here
> https://dist.apache.org/repos/dist/dev/ant/ivy/2.5.0-site-docs/release-notes.html.
>
> The git tag for this release is:
>    
> https://gitbox.apache.org/repos/asf?p=ant-ivy.git;a=tag;h=refs/tags/2.5.0_Vote_RC1
> with SHA for this tag being 48234fc5ede85a865eb874a96c08472ce1751fd1
>
> The artifacts has been published to:
>     https://dist.apache.org/repos/dist/dev/ant/ivy/2.5.0/ at SVN
> revision 36396
>
> The staging Maven repository is available at:
>    
> https://repository.apache.org/content/repositories/orgapacheant-1043/org/apache/ivy/ivy/2.5.0/
>
> The Eclipse updatesite is available here:
>    
> https://dist.apache.org/repos/dist/dev/ant/ivyde/updatesite/ivy-2.5.0.final_20191020104435/
>
>
> This vote will be open for at least 72 hours and will not close before
> 23rd October 2019 12:00 UTC.
>
> - Jaikiran, Ivy 2.5.0 release manager, on behalf of Ivy team
>
>
> -
> 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 14 - Early Access build 19 is available

2019-10-21 Thread Jaikiran Pai
Hello Rory,

No issues[1] observed with this build (JDK 14 build 14-ea+19-824)
against our Ant project on a Linux system.

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

-Jaikiran

On 20/10/19 12:17 PM, Rory O'Donnell wrote:
>  Hi Stefan/Jaikiran,
>
> *OpenJDK builds  - JDK 14 *- Early Access build 19 is available at
> http://jdk.java.net/14/
>
> These early-access, open-source builds are provided under the GNU
> General Public License, version 2, with the Classpath Exception
> .
>
>  * Release notes
>  o https://jdk.java.net/14/release-notes
>
>  * JEPs targeted to JDK 14, so far
>  o 352 - Non-Volatile Mapped Byte Buffers
>    
>  o 358 - Helpful NullPointerExceptions
>    
>  o 349 - JFR Event Streaming 
>  * *I want to draw your attention to some notable changes in previous
>    builds of JDK 14.*
>  o *Build 14* - Classes are now loaded and linked by
>    Class.forName() (JDK-8212117
>    )
>  + we need help testing changes to 3-arg Class.forName method.
>    The method has always been specified to link the class but
>    the implementation has historically not done this when
>    invoked with the "initialize" parameter set to false. The
>    bug has been fixed in JDK 14 but it has the potential to
>    change the behavior of code that uses Class.forName to load
>    classes that cannot be linked.
>
>
>  * Changes in this build
>   
> 
>
>
> *Openjdk Builds - JDK 13.0.1 *General Availability -
> https://jdk.java.net/13/
>
> These early-access, open-source builds are provided under the GNU
> General Public License, version 2, with the Classpath Exception
> .
>
>  * Release notes 
>  * Changes in this release
>   
> 
>
>
> *Crypto roadmap updated*    -
> https://www.java.com/en/jre-jdk-cryptoroadmap.html
>
> Targeted Date^(2) Targeted Release(s) Algorithm/Protocol
> Action How to test/enable change Change Log
> 2019-10-15 13, 11, 8, 7 ECC on TLS Disable non-NIST Suite
> B EC curves (sect283k1, sect283r1, sect409k1, sect409r1, sect571k1,
> sect571r1, secp256k1) when negotiating TLS sessions Disabling
> non-NIST Suite B EC curves when negotiating TLS sessions
> 
> 2019-10-08 Announced.
>
>
> Rgds,Rory
>

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



Re: AW: [VOTE] Release Ivy 2.5.0 based on RC1

2019-10-24 Thread Jaikiran Pai
Hello Jan,

On 24/10/19 1:31 AM, Jan Matèrne (jhm) wrote:
> Checked the bin.zip.
> Seems to be ok.
>
> Just a question: there is a file fr\jayasoft\ivy\ant\antlib.xml which seems 
> to be a copy of org\apache\ivy\ant\antlib.xml. Is it for BWC?
Yes, looks like it.
https://github.com/apache/ant-ivy/blob/master/build.xml#L263. It was
done way back in 2007 and I don't think anyone uses that reference
anymore. After this release, maybe we can stop copying and releasing
that file.
>
> Hello-Ivy-Example:
> - run with "ant -lib ..\..\..\ivy-2.5.0.jar run"
> --> Ivy starts
> --> Ivy vesion 2.5.0
> --> Problems with downloading the dependencies:
>
> [ivy:retrieve]  found commons-lang#commons-lang;2.6 in public
> [ivy:retrieve] You probably access the destination server through a proxy 
> server that is not well configured.
>
> [ivy:retrieve] :: problems summary ::
> [ivy:retrieve]  WARNINGS
> [ivy:retrieve]  Host repo1.maven.org not found. 
> url=https://repo1.maven.org/maven2/commons-cli/commons-cli/1.4/commons-cli-1.4.pom
> [ivy:retrieve]  Host repo1.maven.org not found. 
> url=https://repo1.maven.org/maven2/commons-cli/commons-cli/1.4/commons-cli-1.4.jar
> [ivy:retrieve]  module not found: commons-cli#commons-cli;1.4
> [ivy:retrieve]   local: tried
> [ivy:retrieve]
> C:\Users\Jan\.ivy2\local\commons-cli\commons-cli\1.4\ivys\ivy.xml
> [ivy:retrieve]-- artifact commons-cli#commons-cli;1.4!commons-cli.jar:
> [ivy:retrieve]
> C:\Users\Jan\.ivy2\local\commons-cli\commons-cli\1.4\jars\commons-cli.jar
> [ivy:retrieve]   shared: tried
> [ivy:retrieve]
> C:\Users\Jan\.ivy2\shared\commons-cli\commons-cli\1.4\ivys\ivy.xml
> [ivy:retrieve]-- artifact commons-cli#commons-cli;1.4!commons-cli.jar:
> [ivy:retrieve]
> C:\Users\Jan\.ivy2\shared\commons-cli\commons-cli\1.4\jars\commons-cli.jar
> [ivy:retrieve]   public: tried
> [ivy:retrieve]
> https://repo1.maven.org/maven2/commons-cli/commons-cli/1.4/commons-cli-1.4.pom
> [ivy:retrieve]-- artifact commons-cli#commons-cli;1.4!commons-cli.jar:
> [ivy:retrieve]
> https://repo1.maven.org/maven2/commons-cli/commons-cli/1.4/commons-cli-1.4.jar
>
> I dont have a proxy server I am aware of.
> I could access the url 
> https://repo1.maven.org/maven2/commons-cli/commons-cli/1.4/commons-cli-1.4.jar
>  via browser.
>
> Added a 'get' target which works:
> 
>  src="https://repo1.maven.org/maven2/commons-cli/commons-cli/1.4/commons-cli-1.4.jar";
>  dest="."/>
> 
>
> Another try:
>   ant -lib ..\..\..\ivy-2.5.0.jar -autoproxy run
> and that worked.

I gave this example a try with this released version and it went fine
without those warnings or errors. I suspect your Ivy cache probably had
already downloaded the metadata/resources previously using some other
"resolver"?


> So a +1 from me.
Thank you.
> Thanks for getting the release done.

This was on my TODO list for a very long time now. Glad that this is now
happening.

-Jaikiran



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



[RESULT] Release Ivy 2.5.0 based on RC1

2019-10-24 Thread Jaikiran Pai
With +1s from:

Jaikiran Pai

Stefan Bodewig

Jan Matèrne

and no vetos, this vote now passes. I'll initiate the rest of the
process to complete this release process.

Thank you all for voting.

-Jaikiran

On 24/10/19 9:45 AM, Stefan Bodewig wrote:
> +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



Need help releasing IVY project in JIRA

2019-10-24 Thread Jaikiran Pai
It looks like I don't have relevant permissions in JIRA to release the
IVY project. Can someone with appropriate permissions at
https://issues.apache.org/jira/browse/IVY please rename the "master"
release https://issues.apache.org/jira/projects/IVY/versions/12343084 to
"2.5.0" and officially release it in JIRA?

Once done, please also create a new "master" release so that newer fixes
can be tracked against it.

-Jaikiran


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



Re: AW: Need help releasing IVY project in JIRA

2019-10-24 Thread Jaikiran Pai
Thank you Jan.

-Jaikiran

On 24/10/19 11:32 PM, Jan Matèrne (jhm) wrote:
> done
>
> Jan
>
>> -Ursprüngliche Nachricht-
>> Von: Jaikiran Pai [mailto:jaiki...@apache.org]
>> Gesendet: Donnerstag, 24. Oktober 2019 13:42
>> An: Ant Developers List
>> Betreff: Need help releasing IVY project in JIRA
>>
>> It looks like I don't have relevant permissions in JIRA to release the
>> IVY project. Can someone with appropriate permissions at
>> https://issues.apache.org/jira/browse/IVY please rename the "master"
>> release https://issues.apache.org/jira/projects/IVY/versions/12343084
>> to "2.5.0" and officially release it in JIRA?
>>
>> Once done, please also create a new "master" release so that newer
>> fixes can be tracked against it.
>>
>> -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



[ANNOUNCE] Apache Ivy 2.5.0 released

2019-10-24 Thread Jaikiran Pai
The Apache Ivy project is pleased to announce its 2.5.0 release.

Apache Ivy is a tool for managing (recording, tracking, resolving and
reporting) project dependencies, characterized by flexibility,
configurability, and tight integration with Apache Ant.

Key features of this 2.5.0 release are:

    - The minimum runtime Java version required is now Java 7

    - Ivy now uses BouncyCastle OpenPGP API 1.59. Due to the non
backward compatibility of that library, earlier versions are not supported.

    - Ivy now uses HttpComponents HttpClient 4.5.x version with HTTP
backed resolvers. Users are expected to have this version of the library
(and its dependencies) in their runtime classpath if they want to use
such resolvers. The previous (similarly named but not the same)
commons-httpclient library is no longer used or supported.
(https://issues.apache.org/jira/browse/IVY-1563)


Other than this, there have been numerous issues that have been fixed
(since 2.4.0) and some enhancements too. The complete set of changes is
available in release notes here
https://ant.apache.org/ivy/history/2.5.0/release-notes.html

Migration note:

Users moving from 2.5.0-rc1 are highly recommend to use a fresh/new
local Ivy cache directory for this release, to avoid certain issues with
metadata files that might have been cached in the local directory, from
previous version of Ivy.

Issues should be reported to:
https://issues.apache.org/jira/browse/IVY

Download the release at:
https://ant.apache.org/ivy/download.cgi

More information can be found on the Ivy website:
https://ant.apache.org/ivy/

- Jaikiran, on behalf of Apache Ivy team




signature.asc
Description: OpenPGP digital signature


Re: AW: AW: [VOTE] Release Ivy 2.5.0 based on RC1

2019-10-24 Thread Jaikiran Pai


On 25/10/19 12:13 PM, Jan Matèrne (jhm) wrote:
>>> Just a question: there is a file fr\jayasoft\ivy\ant\antlib.xml which
>> seems to be a copy of org\apache\ivy\ant\antlib.xml. Is it for BWC?
>> Yes, looks like it.
>> https://github.com/apache/ant-ivy/blob/master/build.xml#L263. It was
>> done way back in 2007 and I don't think anyone uses that reference
>> anymore. After this release, maybe we can stop copying and releasing
>> that file.
>
> Done

Thank you Jan.


>
>>> Hello-Ivy-Example:
>>> - run with "ant -lib ..\..\..\ivy-2.5.0.jar run"
>>> --> Ivy starts
>>> --> Ivy vesion 2.5.0
>>> --> Problems with downloading the dependencies:
>>>
>>> [ivy:retrieve]  found commons-lang#commons-lang;2.6 in public
>>> [ivy:retrieve] You probably access the destination server through a proxy 
>>> server that is not well configured.
>>> Another try:
>>>   ant -lib ..\..\..\ivy-2.5.0.jar -autoproxy run and that worked.
>> I gave this example a try with this released version and it went fine
>> without those warnings or errors. I suspect your Ivy cache probably had
>> already downloaded the metadata/resources previously using some other
>> "resolver"?
> Deleted %userprofile%/.ivy2 and it worked without the -autoproxy.
>
Happy to hear that.

-Jaikiran


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



Next plans for Ivy

2019-10-30 Thread Jaikiran Pai
Now that Ivy 2.5.0 has been released, I would like to propose the
following ideas for the next goals for the project:

1. I would like to wait and watch for any bug reports for 2.5.0 and do
some relatively frequent bug fix releases for that version. So
essentially 2.5.x versions which are solely bug fixes. To accommodate
that, I would like to create a 2.5 branch in the Ivy project. Ivy 2.5.x
will continue to have minimum Java 7 as a requirement. Once we are
confident that the 2.5.x series is stable enough, we can stop releases
off that branch.

2. In the master branch, I would like to move Ivy to minimum Java 8
version (right now we are on minimum Java 7). I would like to mention
that, just because we move to Java 8, the goal isn't large/medium scale
refactoring of existing code. This is especially important given the
nature of the project - the code base is complex plus we don't have
enough knowledge of it. It literally took me months to be able to read
the code and understand what I'm dealing with to be able to confidently
do a change that could fix some of the recent bugs (especially
IVY-1580). So even though we will move to Java 8, any refactoring, just
for the sake of it, of existing code will be discouraged. Of course, if
new code is being added, Java 8 constructs/API are welcome. Also if a
bug fix requires Java 8 construct/API that's welcome too. We will do
2.6.x releases (whenever we decide to do so) off master branch.

Any objections to these plans?

-Jaikiran



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



Re: Next plans for Ivy

2019-11-01 Thread Jaikiran Pai
Hello Matt,

On 31/10/19 2:34 AM, Matt Sicker wrote:
> Java 9 and beyond can be handled with version specific code in META-INF.

I think we should be able to do that even now. Of course, _building_ Ivy
would need higher version of Java (to use those specific APIs) but once
built, we can package these higher version classes within the META-INF
structure and that should get picked up if someone uses Ivy in a higher
version of Java and at the same time shouldn't impact Java 8 usage.

-Jaikiran

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



Re: JDK 14 - Early Access build 22 is available

2019-11-16 Thread Jaikiran Pai
Hello Rory,

No issues observed with JDK 14 build 14-ea+23-1048 on our Linux system
against the Ant project
https://builds.apache.org/job/Ant%20Master%20(latest%20EA%20JDK)/jdk_axis=jdk14-ea,label_exp=ubuntu/25/

-Jaikiran

On 12/11/19 3:10 PM, Rory O'Donnell wrote:
>  Hi Stefan/Jaikiran,
>
> *OpenJDK builds  - JDK 14 *- Early Access build 22 is available at
> http://jdk.java.net/14/
>
> These early-access, open-source builds are provided under the GNU
> General Public License, version 2, with the Classpath Exception
> .
>
>  * Release notes
>  o https://jdk.java.net/14/release-notes
>
>  * JEPs targeted to JDK 14, so far:
>
>  * JEP 345: NUMA-Aware Memory Allocation for G1
>     was Targeted to JDK 14.
>  * JEP 349: JFR Event Streaming
>     was Integrated.
>  * JEP 361: Switch Expressions (Standard)
>     was Targeted to JDK 14.
>  * JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage
>    Collector  was Targeted to
> JDK 14.
>  * JEP 364: ZGC on macOS  was
>    Targeted to JDK 14.
>  * JEP 365: ZGC on Windows  moved
>    to Candidate.
>  * JEP 366: Deprecate the ParallelScavenge + SerialOld GC
>    Combination  was Proposed to
>    target JDK 14.
>  * JEP 367: Remove the Pack200 Tools and API
>     was Targeted to JDK 14.
>  * JEP 368: Text Blocks (Second Preview)
>     moved to Candidate.
>
>  * Changes in this build
>   
> 
>
> *jpackage EA -* Build 14-jpackage+1-67 (2019/11/4)
>
>  * 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.
>  * These early-access builds are provided under the GNU General Public
>    License, version 2, with the Classpath Exception
>    
>  * Build 14 is now available http://jdk.java.net/jpackage/
>  * Please send feedback via e-mail to core-libs-...@openjdk.java.net
>    
>
>
>

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



Re: JDK 14 - Early Access build 25 is available

2019-12-02 Thread Jaikiran Pai
Hello Rory,

No issues found with this JDK 14 build 14-ea+25-1178 against our Ant
project on a Linux system
https://builds.apache.org/job/Ant%20Master%20(latest%20EA%20JDK)/jdk_axis=jdk14-ea,label_exp=ubuntu/26/

-Jaikiran

On 29/11/19 3:13 PM, Rory O'Donnell wrote:
>  Hi Stefan/Jaikiran,
>
> *OpenJDK builds  - JDK 14 *- Early Access build 25 is available at
> http://jdk.java.net/14/
>
> These early-access, open-source builds are provided under the GNU
> General Public License, version 2, with the Classpath Exception
> .
>
>  * *Next Milestone*
>    **
>  o ** *12-Dec-2019 Rampdown Phase One.*
>
>  * Release notes
>  o https://jdk.java.net/14/release-notes
>  * JEP proposed to target JDK 14
>  o JEP 365 ZGC on Windows 
>  * JEPs targeted to JDK 14, so far:
>  o JEP 305: Pattern Matching for instanceof (Preview)
>     was proposed to target.
>  o JEP 343: Packaging Tool (Incubator)
>     was proposed to target.
>  o JEP 345: NUMA-Aware Memory Allocation for G1
>     was integrated.
>  o JEP 349: JFR Event Streaming
>     was integrated.
>  o JEP 352: Non-Volatile Mapped Byte Buffers
>     was targeted.
>  o JEP 358: Helpful NullPointerExceptions
>     was integrated.
>  o JEP 359: Records (Preview) 
>    JEP 359: Records (Preview)
>     was proposed to target.
>  o JEP 361: Switch Expressions (Standard)
>     was intergrated.
>  o JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage
>    Collector  was targeted.
>  o JEP 364: ZGC on macOS  was
>    targeted.
>  o JEP 366: Deprecate the ParallelScavenge + SerialOld GC
>    Combination  was proposed to
>    target.
>  o JEP 367: Remove the Pack200 Tools and API
>     was targeted to JDK 14.
>  o JEP 368: Text Blocks (Second Preview)
>     was proposed to target.
>
>  * Recent Bug fixes of Interest
>
>  * Build 25:
>  o JDK-8233301: Implementation of JEP 366: Deprecate the
>    ParallelScavenge + SerialOld GC Combination
>  o JDK-8233296: The behavior of MulticastSocket
>    getOption/setOption for IP_MULTICAST_LOOP is changed to
>    conform the specification of
>    StandardSocketOptions.IP_MULTICAST_LOOP
>  * Build 24:
>  o JDK-8233141 :DatagramSocket.send and MulticastSocket.send
>    throw IllegalArgumentException when the socket is not
>    connected and the packet doesn't contain any address )
>  o JDK-8214024: Remove the default keytool -keyalg value
>  o JDK-8232019: Add LuxTrust certificate updates to the
>    existing root program
>  * Build 23
>  o JDK 8232365: Implementation for JEP 363: Remove the
>    Concurrent Mark Sweep (CMS) Garbage Collector
>  o JDK 8224817: Implementation of JEP 364: ZGC on macOS
>
>  * Changes in this build
>   
> 
>
> *jpackage EA -* Build 14-jpackage+1-70 (2019/11/12)
>
>  * 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.
>  * These early-access builds are provided under the GNU General Public
>    License, version 2, with the Classpath Exception
>    
>  * Build is now available http://jdk.java.net/jpackage/
>  * Please send feedback via e-mail to core-libs-...@openjdk.java.net
>    
>
> Rgds,Rory**
> **
>

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



Re: JDK 14 enters Rampdown Phase One

2019-12-21 Thread Jaikiran Pai
Hello Rory,

I forgot to reply to this earlier this week. Our tests on a Linux system
against this version (JDK 14 build 14-ea+27-1339) have passed without
any unexpected failures[1].

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

-Jaikiran

On 14/12/19 9:53 PM, Rory O'Donnell wrote:
>
>   Hi Stefan/Jaikiran,
>
> *Per the JDK 14 schedule , we are now in Rampdown Phase One*
>
> *Please advise if you have found any issues while testing the latest
> Early Access build.
> *
>
>  * Schedule for JDK 14
>  o *2019/12/12 Rampdown Phase One*
>  o 2020/01/16 Rampdown Phase Two
>  o 2020/02/06 Initial Release Candidate
>  o 2020/02/20 Final Release Candidate
>  o 2020/03/17 General Availability
>
>  * The overall feature set is frozen.
>  o No further JEPs will be targeted to this release
>  o For more details , see Mark Reinhold's email to jdk-dev mailing
>    list [1]
>
>  * Features included in JDK 14:.
>  o JEP 305: Pattern Matching for instanceof (Preview)
>    
>  o JEP 343: Packaging Tool (Incubator)
>    
>  o JEP 345: NUMA-Aware Memory Allocation for G1
>    
>  o JEP 349: JFR Event Streaming 
>  o JEP 352: Non-Volatile Mapped Byte Buffers
>    
>  o JEP 358: Helpful NullPointerExceptions
>    
>  o JEP 359: Records (Preview) 
>    JEP 359: Records (Preview) 
>  o JEP 361: Switch Expressions (Standard)
>    
>  o JEP 362: Deprecate the Solaris and SPARC Ports
>    
>  o JEP 363: Remove the Concurrent Mark Sweep Garbage Collector
>    
>  o JEP 364: ZGC on macOS 
>  o JEP 365 ZGC on Windows 
>  o JEP 366: Deprecate ParallelScavenge  SerialOld GC Combination
>    
>  o JEP 367: Remove the Pack200 Tools and API
>    
>  o JEP 368: Text Blocks (Second Preview)
>    
>  o JEP 370: Foreign-Memory Access API (Incubator)
>    
>
> *JDK 14 **Early Access build 27 **is available**at : - jdk.java.net/14/*
>
>  * Release notes
>  o https://jdk.java.net/14/release-notes
>  * Recent fixes that might be of interest
>  o Build 27:
>  + JDK-8212780: Packaging Tool Implementation
>  + JDK-8234370: Implementation of JEP 362: Deprecate the
>    Solaris and SPARC Ports
>  + JDK-8190492: Remove SSLv2Hello and SSLv3 from default
>    enabled TLS protocols
>  + JDK-8214481: freetype path does not disable TrueType hinting
>    with AA+FM hints
>  + JDK-8234076: JVM crashes on Windows 10 using --module=NAME
>  + JDK-8222756: Plural support in CompactNumberFormat
>  + JDK-8234211: allow discoverable javac plugins to be invoked
>    by default
>  o Build 26:
>  + JDK-8233223: Add Amazon Root CA certificates
>  + JDK-8235263: Revert TLS 1.3 change that wrapped IOExceptions
>  + JDK-8234893: ARM32: build failure after JDK-8234387
>
> Rgds, Rory
>
> [1]
> https://mail.openjdk.java.net/pipermail/jdk-dev/2019-December/003795.html
>
>

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



Time for 1.10.8 release?

2020-01-10 Thread Jaikiran Pai
I just noticed that we have added some good number of bug fixes[1] since
our 1.10.7 release and it's been already 4 months since that release. If
no one has any objections then I'll go ahead and start a vote for 1.10.8
release, in the next few days.

[1] https://github.com/apache/ant/blob/master/WHATSNEW#L1

-Jaikiran


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



Re: Time for 1.10.8 release?

2020-01-10 Thread Jaikiran Pai
There's time. If it's a straightforward PR, I'll merge it.

-Jaikiran

On 10/01/20 7:46 pm, Gintautas Grigelionis wrote:
> I was planning a tiny PR to update the third party libraries, if there's
> time still.
>
> Gintas
>
> On Fri, 10 Jan 2020 at 14:54, Jaikiran Pai  wrote:
>
>> I just noticed that we have added some good number of bug fixes[1] since
>> our 1.10.7 release and it's been already 4 months since that release. If
>> no one has any objections then I'll go ahead and start a vote for 1.10.8
>> release, in the next few days.
>>
>> [1] https://github.com/apache/ant/blob/master/WHATSNEW#L1
>>
>> -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: JDK 14 Early Access build 30 & JDK 15 Early Access build 4 are available.

2020-01-10 Thread Jaikiran Pai
Hello Rory,

A very happy new year to you too!

We have run our Ant testsuite on a Linux setup against the following EA
versions and have noticed no issues.

JDK 14 build 14-ea+30-1385 -
https://builds.apache.org/job/Ant%20Master%20(latest%20EA%20JDK)/jdk_axis=jdk14-ea,label_exp=ubuntu/28/

JDK 15 build 15-ea+4-63 -
https://builds.apache.org/job/Ant%20Master%20(latest%20EA%20JDK)/jdk_axis=jdk15-ea,label_exp=ubuntu/28/

-Jaikiran

On 06/01/20 3:52 pm, Rory O'Donnell wrote:
> Hi Stefan/Jaikiran,
>
> Happy New Year !
>
> *Per the JDK 14 schedule , we are now in Rampdown Phase One*
>
> *Please advise if you have found any issues while testing the latest
> Early Access build.
> *
>
>  * The overall feature set is frozen.
>  o No further JEPs will be targeted to this release
>  o For more details , see Mark Reinhold's email to jdk-dev mailing
>    list [1]
>
> *JDK 14 **Early Access build 30 **is available**at : - jdk.java.net/14/*
>
>  * These early-access , open-source builds are provided under the
>  o GNU General Public License, version 2, with the Classpath
>    Exception .
>  * Release notes
>  o https://jdk.java.net/14/release-notes
>  * Recent fixes that might be of interest
>  o Build 29:
>  + JDK-8233228: Disable weak named curves by default in TLS,
>    CertPath, and Signed JAR
>
>  o Build 28:
>  + JDK-8234049: Implementation of Memory Access API (Incubator)
>  + JDK-8235668: LineNumberReader#getLineNumber() returns wrong
>    line number (one fewer) in Lucene test
>  # Reported by Apache Lucene
>
> *JDK 15 **Early Access build 4 **is available**at : - jdk.java.net/15/*
>
>  * These early-access , open-source builds are provided under the
>  o GNU General Public License, version 2, with the Classpath
>    Exception .
>  * Release notes
>  o http://jdk.java.net/15/release-notes
>
> The Quality Outreach Report for Decemeber 2019 was published since the
> last email
>
>  *
> https://wiki.openjdk.java.net/display/quality/Quality+Outreach+report+December+2019
>  * Many thanks to all those who contributed to testing, logging bugs
>    etc against the Early Access builds.
>
> *
> *
>
> Rgds, Rory
>
> [1]
> https://mail.openjdk.java.net/pipermail/jdk-dev/2019-December/003795.html
>

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



Re: Reference to http://repo1.maven.org/maven2, now blocked with 501 error

2020-01-16 Thread Jaikiran Pai
Hello Davide,

On 16/01/20 2:54 pm, Davide Grandi wrote:
> Good morning Ant developers,
>
> since yesterday the http access to repo1.maven.org is blocked.

Thank you for bringing this to our notice.


> It happens that in trunk file
>     lib\libraries.properties
> at line 21, there's a such reference
> -- 
> m2.version=2.0.4
> m2.url=http\://repo1.maven.org/maven2
> m2.artifact-name=maven-artifact-ant
> -- 
>
We changed it to use https back in May 2019. The latest
lib/libraries.properties[1] is using https.

[1] https://github.com/apache/ant/blob/master/lib/libraries.properties

-Jaikiran


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



  1   2   3   4   5   6   >