Re: FYI

2019-07-22 Thread Andrea Del Bene 
After the fix applied by Martin we have another more strange message error
during javadoc:aggregate. I couldn't find any possible cause yet:

[INFO] --- maven-javadoc-plugin:3.1.1:aggregate (default-cli) @
wicket-parent ---
[INFO] Toolchain in maven-javadoc-plugin:
JDK[/usr/lib/jvm/adoptopenjdk-11-jdk-hotspot/]
[WARNING] Only outputDirectories and jars are accepted on the path
[ERROR] no reactor project: org.apache.wicket:wicket
[ERROR] Error while creating javadoc report: Only outputDirectories and
jars are accepted on the path
java.lang.IllegalArgumentException: Only outputDirectories and jars are
accepted on the path
at org.codehaus.plexus.languages.java.jpms.LocationManager.resolvePath
(LocationManager.java:333)
at org.codehaus.plexus.languages.java.jpms.LocationManager.resolvePath
(LocationManager.java:139)
at
org.apache.maven.plugins.javadoc.AbstractJavadocMojo.addJavadocOptions
(AbstractJavadocMojo.java:5001)
at org.apache.maven.plugins.javadoc.AbstractJavadocMojo.executeReport
(AbstractJavadocMojo.java:2081)
...

On Sat, Jul 13, 2019 at 10:22 PM Martin Grigorov 
wrote:

> Hi,
>
> I've committed a change to Wicket's Buildbot config that adds JAVA_HOME for
> the Java 11, 13 and 14 builds.
> Hopefully this will fix the problem!
>
> On Fri, Jul 12, 2019 at 5:01 PM Andrea Del Bene 
> wrote:
>
> > Problem with javadoc-maven-plugin 3.1.x and CI:
> >
> > https://issues.apache.org/jira/browse/INFRA-18741
> >
> > --
> > Andrea Del Bene.
> > Apache Wicket committer.
> >
>


-- 
Andrea Del Bene.
Apache Wicket committer.

[GitHub] [wicket] martin-g merged pull request #377: WICKET-6689 fix ClientProperties.getTimezone() UTC-DST difference calculation.

2019-07-22 Thread GitBox 
martin-g merged pull request #377: WICKET-6689 fix 
ClientProperties.getTimezone() UTC-DST difference calculation.
URL: https://github.com/apache/wicket/pull/377
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

Re: JDK 13 enters Rampdown Phase Two

2019-07-22 Thread Martin Grigorov 
Hi Muneer,

Yes, this ticket explains the problem:

Etc/UCT is now a backward-compatibility link to Etc/UTC, instead
 of being a separate zone that generates the abbreviation "UCT",
 which nowadays is typically a typo. (Problem reported by Isiah
 Meadows.)

So it seems there is no need of a ticket.

Otherwise the reproducer is :import java.time.ZonedDateTime;
import java.time.format.DateTimeFormatter;
import java.time.format.FormatStyle;
import java.time.temporal.TemporalAccessor;
import java.util.Locale;

public class Java13Build30
{
   public static void main(String[] args)
   {
  String toParse = "Jul 11, 2016, 1:02:03 AM Coordinated Universal
Time";
  Locale locale = Locale.ENGLISH;
  DateTimeFormatter dateTimeFormatter =
DateTimeFormatter.ofLocalizedDateTime(FormatStyle.MEDIUM,
FormatStyle.FULL).withLocale(locale);
  final TemporalAccessor temporalAccessor =
dateTimeFormatter.parse(toParse);
  final ZonedDateTime zonedDateTime =
ZonedDateTime.from(temporalAccessor);
  System.err.println(zonedDateTime);
   }
}

Regards,
Martin

On Mon, Jul 22, 2019 at 3:40 PM  wrote:

> Hi Martin,
>
> This enhancement task description may help you: 
> https://bugs.openjdk.java.net/browse/JDK-8224560
> .
> 
>
> It is included in JDK 13 build 30.
>
> -Muneer
>
> On 22/07/19 6:00 PM, Rory O'Donnell wrote:
>
> Hi Martin,
>
> A reproducer would be great.
>
> Thanks,Rory
> On 22/07/2019 13:03, Martin Grigorov wrote:
>
> Hi,
>
> I won't have time now to extract a mini reproducer but if anyone else has
> time here are some details:
>
> the test tries to parse "Jul 11, 2016, 1:02:03 AM Coordinated Universal
> Time" with Locale.ENGLISH
> In earlier versions of Java it returns a ZonedDateTime.of(2016, 7, 11, 1,
> 2, 3, 0, ZoneId.of("Etc/UCT"))
> with Java 13 b30 the zone id is "Etc/UTC"
> I am not sure what UCT is and whether it is a valid zone, but it seems to
> be a valid one.
>
> On Mon, Jul 22, 2019 at 2:48 PM Martin Grigorov 
> wrote:
>
>> Hi Rory,
>>
>> There is a test failure with Java 13 build 30 in Apache Wicket:
>>
>> INFO] Results:
>> [INFO]
>> [ERROR] Failures:
>> [ERROR]   ZonedDateTimeConverterTest.convertToObject:46 expected:
>> <2016-07-11T01:02:03Z[Etc/UTC]> but was: <2016-07-11T01:02:03Z[Etc/UCT]>
>>
>> Java 13 returns UCT instead of UTC as a ZoneId.
>> Is this expected ?
>>
>> Regards,
>> Martin
>>
>>
>> On Mon, Jul 22, 2019 at 1:18 PM Rory O'Donnell 
>> wrote:
>>
>>> Hi Martin,
>>>
>>> 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
>>>
>>>
>>> --
>>> Rgds, Rory O'Donnell
>>> Quality Engineering Manager

Re: JDK 13 enters Rampdown Phase Two

2019-07-22 Thread abdul . kolarkunnu 

Hi Martin,

This enhancement task description may help you: 
https://bugs.openjdk.java.net/browse/JDK-8224560 .


It is included in JDK 13 build 30.

-Muneer


On 22/07/19 6:00 PM, Rory O'Donnell wrote:


Hi Martin,

A reproducer would be great.

Thanks,Rory

On 22/07/2019 13:03, Martin Grigorov wrote:

Hi,

I won't have time now to extract a mini reproducer but if anyone else 
has time here are some details:


the test tries to parse "Jul 11, 2016, 1:02:03 AM Coordinated 
Universal Time" with Locale.ENGLISH
In earlier versions of Java it returns a ZonedDateTime.of(2016, 7, 
11, 1, 2, 3, 0, ZoneId.of("Etc/UCT"))

with Java 13 b30 the zone id is "Etc/UTC"
I am not sure what UCT is and whether it is a valid zone, but it 
seems to be a valid one.


On Mon, Jul 22, 2019 at 2:48 PM Martin Grigorov > wrote:


Hi Rory,

There is a test failure with Java 13 build 30 in Apache Wicket:

INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR]   ZonedDateTimeConverterTest.convertToObject:46 expected:
<2016-07-11T01:02:03Z[Etc/UTC]> but was:
<2016-07-11T01:02:03Z[Etc/UCT]>

Java 13 returns UCT instead of UTC as a ZoneId.
Is this expected ?

Regards,
Martin


On Mon, Jul 22, 2019 at 1:18 PM Rory O'Donnell
mailto:rory.odonn...@oracle.com>> wrote:

Hi Martin,

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


-- 
Rgds, Rory O'Donnell

Quality Engineering Manager
Oracle EMEA, Dublin, Ireland


--
Rgds, Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin, Ireland

Re: JDK 13 enters Rampdown Phase Two

2019-07-22 Thread Rory O'Donnell 

Hi Martin,

A reproducer would be great.

Thanks,Rory

On 22/07/2019 13:03, Martin Grigorov wrote:

Hi,

I won't have time now to extract a mini reproducer but if anyone else 
has time here are some details:


the test tries to parse "Jul 11, 2016, 1:02:03 AM Coordinated 
Universal Time" with Locale.ENGLISH
In earlier versions of Java it returns a ZonedDateTime.of(2016, 7, 11, 
1, 2, 3, 0, ZoneId.of("Etc/UCT"))

with Java 13 b30 the zone id is "Etc/UTC"
I am not sure what UCT is and whether it is a valid zone, but it seems 
to be a valid one.


On Mon, Jul 22, 2019 at 2:48 PM Martin Grigorov > wrote:


Hi Rory,

There is a test failure with Java 13 build 30 in Apache Wicket:

INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR]   ZonedDateTimeConverterTest.convertToObject:46 expected:
<2016-07-11T01:02:03Z[Etc/UTC]> but was:
<2016-07-11T01:02:03Z[Etc/UCT]>

Java 13 returns UCT instead of UTC as a ZoneId.
Is this expected ?

Regards,
Martin


On Mon, Jul 22, 2019 at 1:18 PM Rory O'Donnell
mailto:rory.odonn...@oracle.com>> wrote:

Hi Martin,

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


-- 
Rgds, Rory O'Donnell

Quality Engineering Manager
Oracle EMEA, Dublin, Ireland


--
Rgds, Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin, Ireland

Re: JDK 13 enters Rampdown Phase Two

2019-07-22 Thread Martin Grigorov 
Hi,

I won't have time now to extract a mini reproducer but if anyone else has
time here are some details:

the test tries to parse "Jul 11, 2016, 1:02:03 AM Coordinated Universal
Time" with Locale.ENGLISH
In earlier versions of Java it returns a ZonedDateTime.of(2016, 7, 11, 1,
2, 3, 0, ZoneId.of("Etc/UCT"))
with Java 13 b30 the zone id is "Etc/UTC"
I am not sure what UCT is and whether it is a valid zone, but it seems to
be a valid one.

On Mon, Jul 22, 2019 at 2:48 PM Martin Grigorov 
wrote:

> Hi Rory,
>
> There is a test failure with Java 13 build 30 in Apache Wicket:
>
> INFO] Results:
> [INFO]
> [ERROR] Failures:
> [ERROR]   ZonedDateTimeConverterTest.convertToObject:46 expected:
> <2016-07-11T01:02:03Z[Etc/UTC]> but was: <2016-07-11T01:02:03Z[Etc/UCT]>
>
> Java 13 returns UCT instead of UTC as a ZoneId.
> Is this expected ?
>
> Regards,
> Martin
>
>
> On Mon, Jul 22, 2019 at 1:18 PM Rory O'Donnell 
> wrote:
>
>> Hi Martin,
>>
>> 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
>>
>>
>> --
>> Rgds, Rory O'Donnell
>> Quality Engineering Manager
>> Oracle EMEA, Dublin, Ireland
>>
>>

Re: JDK 13 enters Rampdown Phase Two

2019-07-22 Thread Martin Grigorov 
Hi Rory,

There is a test failure with Java 13 build 30 in Apache Wicket:

INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR]   ZonedDateTimeConverterTest.convertToObject:46 expected:
<2016-07-11T01:02:03Z[Etc/UTC]> but was: <2016-07-11T01:02:03Z[Etc/UCT]>

Java 13 returns UCT instead of UTC as a ZoneId.
Is this expected ?

Regards,
Martin


On Mon, Jul 22, 2019 at 1:18 PM Rory O'Donnell 
wrote:

> Hi Martin,
>
> 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
>
>
> --
> Rgds, Rory O'Donnell
> Quality Engineering Manager
> Oracle EMEA, Dublin, Ireland
>
>