Re: Testing Apache Wicket with JDK Early Access builds
Java 13 is installed now: https://ci.apache.org/builders/wicket-master-java13/builds/1/steps/compile/logs/stdio On Mon, Jan 21, 2019 at 10:53 AM Tobias Soloschenko wrote: > Thanks a lot Martin! > > kind regards > > Tobias > > > Am 21.01.2019 um 08:47 schrieb Martin Grigorov : > > > > https://issues.apache.org/jira/browse/INFRA-17710 > > > > On Mon, Jan 21, 2019 at 9:42 AM Martin Grigorov > > wrote: > > > >> Thanks for noticing this, Tobias! > >> I checked that wicket-master-java12 fails with the Weld issue and just > >> assumed -java13 fails the same way. > >> > >> We should ask Infra to add Java 13 to the toolchains! > >> > >> On Sun, Jan 20, 2019 at 7:43 PM Tobias Soloschenko > >> wrote: > >> > >>> Hi, > >>> > >>> sorry for catching up so late, but do we need to ask infra to add jdk > 13 > >>> to also test the ea build? > >>> > >>> I just saw that it is missing in the toolchain XML file and I wonder if > >>> it is already available? > >>> > >>> > >>> > https://ci.apache.org/builders/wicket-master-java13/builds/0/steps/compile/logs/stdio > >>> > >>> kind regards > >>> > >>> Tobias > >>> > Am 18.01.2019 um 17:06 schrieb Martin Grigorov >: > > Hi Rory, > > No objections from me but honestly most of us still run our apps on > >>> Java 8 > at our daily jobs. > We are not aware of any issues with Java 9+ though! > > > On Fri, Jan 18, 2019, 17:11 Rory O'Donnell >>> wrote: > > > > Hi Martin, > > > > Is it ok if I add to the comments section: > > > > #WorksFineOnJDK9 > > > > #WorksLikeHeavenOnJDK11 > > > > Rgds,Rory > > On 18/01/2019 14:42, Martin Grigorov wrote: > > > > Hi Rory, > > > > I've created https://issues.jboss.org/browse/WELD-2559 for the issue > >>> with > > JBoss Weld. > > > > We would like to be listed at [1]! > > Contact name: Apache Wicket team (if it has to be a single person > then: > > Martin Grigorov) > > Mailing list: dev@wicket.apache.org > > CIs: > > - https://ci.apache.org/builders/wicket-branch-8.x (Wicket 8.x built > > against Java 8) > > - https://ci.apache.org/builders/wicket-master (Wicket 9.x built > >>> against > > Java 11) > > - https://ci.apache.org/builders/wicket-master-java12 (Wicket 9.x > >>> built > > against Java 12) > > - https://ci.apache.org/builders/wicket-master-java13 (Wicket 9.x > >>> built > > against Java 13) > > > > Please let us know if anything else is needed from our end! > > > > Kind regards, > > Martin > > > > On Fri, Jan 18, 2019 at 3:03 PM Rory O'Donnell < > >>> rory.odonn...@oracle.com> > > wrote: > > > >> Hi Martin, > >> > >> I haven't seen or know of the issue you mentioned below ? > >> > >> I send out email every 2-3 weeks depending on contents of the > builds, > >> example attached. > >> I try to highlight significant changes in the builds, allowing you > to > >> decide if you might want > >> to test with a particular build. We don't expect you to test every > >>> build, > >> it's entirely up to you. > >> If you would like us to list your project on the Quality Outreach > wiki > >> [1] , can you provide a > >> > >> contact name , mailing list (dev@wicket.apache.org) , let us know > the > >> status of testing JDK 8, > >> > >> JDK 11,JDK 12/JDK 13 EA builds and finally a CI if possible ? > >> > >> Rgds,Rory > >> > >> [1] https://wiki.openjdk.java.net/display/quality/Quality+Outreach > >> On 18/01/2019 08:08, Martin Grigorov wrote: > >> > >> Hi Dalibor, Rory, > >> > >> Thank you for inviting us in this initiative! > >> We, the Apache Wicket team, will be glad to help by testing Wicket > >>> with > >> latest OpenJDK builds! > >> Please use dev@wicket.apache.org for further communication. > >> > >> I've just tested Wicket build with openjdk-12-ea+28_linux-x64 > >> and openjdk-13-ea+4_linux-x64 and the only problem is: > >> > >> > >> [ERROR] testPropagationAllHybrid Time elapsed: 0.001 s <<< ERROR! > >> org.jboss.weld.exceptions.WeldException: WELD-001524: Unable to load > >> proxy class for bean Implicit Bean > [javax.enterprise.inject.Instance] > >>> with > >> qualifiers [@Default] with class interface > >>> javax.enterprise.inject.Instance > >> using classloader > >>> jdk.internal.loader.ClassLoaders$AppClassLoader@1b6d3586 > >> Caused by: org.jboss.weld.exceptions.WeldException: WELD-001524: > >>> Unable > >> to load proxy class for bean Implicit Bean > >> [javax.enterprise.inject.Instance] with qualifiers [@Default] with > >>> class > >> interface javax.enterprise.inject.Instance using classloader > >> jdk.internal.loader.ClassLoaders$AppClassLoader@1b6d3586 > >> Caused by: java.lang.NoClassDefFoundError: Could not initialize > class > >>
Re: Future releases and random thoughts
On Mon, Jan 21, 2019 at 9:25 AM Martin Grigorov wrote: > > Speaking of future developments for Wicket 9, I've got (so far) a couple > > of nice-to-have: > > > > - Use Java modularization (project Jigsaw): we should work to fully > > embrace the new modularization framework. If I remember correctly Martin > > has done some work with automatic modules but I can't find the exact > > commit at the moment. > > > > I cannot find it either! Somehow it got lost! > http://branchandbound.net/blog/java/2017/12/automatic-module-name/ - this > article explains the required changes. > > But apart from this minimal change I am not sure we should go fully Jigsaw. > Many libraries still do not support Java 9 modules - > https://blog.frankel.ch/hard-look-state-java-modularization/ > Servlet specification is not updated to make use of Jigsaw and the web > containers do not make use of it. Yup, I'm not sure modularization should currently be our main focus. When Java EE supports it, we can follow suit. > > - Dismiss utility classes Time and Duration: Wicket still heavily use a > > couple of classes from package org.apache.wicket.util.time: Time and > > Duration. These classes are virtually equivalent to java.time.Instant > > and java.time.Duration. I'm aware that this is not a trivial task and > > it's quite delicate, but I'd really like to not depend on custom code > > for tasks like time and dates that are well supported by Java. For those > > who are interested I've started to make some experiment with this task > > and the results are very encouraging as most of the changes are in-place > > replacements of the old classes with the standard entities. You can find > > the code here: https://github.com/bitstorm/wicket/tree/remove-time-utils > > > +1 if the migratiin is easy > The Wicket classes should stay as deprecated for the lifetime of 9.x though I'm not directly opposed to deprecating them in 8.x (though we are at 8.3 soon, so might be a tad late for deprecation) and removing in 9.0 (or making them module private :-D) Martijn
Re: Wicket HTML5 compliancy?
Wicket's markup strategy is garbage in, garbage out. If you don't make your components' and pages' markup HTML5 compliant, then Wicket can't do anything about that. It might be that 3rd party or components from Wicket core are not HTML5 compliant. We gladly accept patches that fix HTML5 compliancy, and won't mess up CSS styling for our thousands of users. So a HTML 5 validator might complain that a can't be in a , but if we 'fix' that by making the into a , to satisfy the validator, we will break all CSS rules that assums ... In short: in principle Wicket doesn't require, prescribe or prevent HTML5 compliancy. It is what you make of it. Also, we use(d) a HTML5 validator filter in our project that would validate the markup sent to the browser on the server side. Due to the rewrites of the HTML parser the project became stale, but I'd love to see it updated and revitalized. https://github.com/dashorst/wicket-stuff-markup-validator Martijn On Mon, Jan 21, 2019 at 10:22 AM Rob Audenaerde wrote: > > Hi all, > > I'm trying to answer the question for one of our clients, that is, if the > application we made using Wicket is HTML5 compliant. > > I have two questions: > > 1. Should Wicket adhere strictly to the standard? > 2. What do you think would be a good approach for testing this? > > Let me describe what I did so far: > > I interpreted this question for myself as: is the HTML output of Wicket > valid HTML5? > > I do this by validating the HTML ouput of some pages of the application > with the https://validator.w3.org/nu. I get a list of warnings, which might > be solved by how Wicket generates HTML and some that might be solved by how > we implemented some detail. > > I also validated a wicket-examples page, I just took the first ajax-example: > > https://validator.w3.org/nu/?doc=http%3A%2F%2Fexamples8x.wicket.apache.org%2Fajax%2Fautocomplete > > As you can see from opening this URL, there are some warnings and some > errors > > I don't see any problem with the examples *working*, so browsers probably > don't care too much, and maybe this is a bit of a non-issue. > > WDYT? > > Kind regards, > Rob Audenaerde -- Become a Wicket expert, learn from the best: http://wicketinaction.com
Wicket HTML5 compliancy?
Hi all, I'm trying to answer the question for one of our clients, that is, if the application we made using Wicket is HTML5 compliant. I have two questions: 1. Should Wicket adhere strictly to the standard? 2. What do you think would be a good approach for testing this? Let me describe what I did so far: I interpreted this question for myself as: is the HTML output of Wicket valid HTML5? I do this by validating the HTML ouput of some pages of the application with the https://validator.w3.org/nu. I get a list of warnings, which might be solved by how Wicket generates HTML and some that might be solved by how we implemented some detail. I also validated a wicket-examples page, I just took the first ajax-example: https://validator.w3.org/nu/?doc=http%3A%2F%2Fexamples8x.wicket.apache.org%2Fajax%2Fautocomplete As you can see from opening this URL, there are some warnings and some errors I don't see any problem with the examples *working*, so browsers probably don't care too much, and maybe this is a bit of a non-issue. WDYT? Kind regards, Rob Audenaerde
Re: Testing Apache Wicket with JDK Early Access builds
Thanks a lot Martin! kind regards Tobias > Am 21.01.2019 um 08:47 schrieb Martin Grigorov : > > https://issues.apache.org/jira/browse/INFRA-17710 > > On Mon, Jan 21, 2019 at 9:42 AM Martin Grigorov > wrote: > >> Thanks for noticing this, Tobias! >> I checked that wicket-master-java12 fails with the Weld issue and just >> assumed -java13 fails the same way. >> >> We should ask Infra to add Java 13 to the toolchains! >> >> On Sun, Jan 20, 2019 at 7:43 PM Tobias Soloschenko >> wrote: >> >>> Hi, >>> >>> sorry for catching up so late, but do we need to ask infra to add jdk 13 >>> to also test the ea build? >>> >>> I just saw that it is missing in the toolchain XML file and I wonder if >>> it is already available? >>> >>> >>> https://ci.apache.org/builders/wicket-master-java13/builds/0/steps/compile/logs/stdio >>> >>> kind regards >>> >>> Tobias >>> Am 18.01.2019 um 17:06 schrieb Martin Grigorov : Hi Rory, No objections from me but honestly most of us still run our apps on >>> Java 8 at our daily jobs. We are not aware of any issues with Java 9+ though! > On Fri, Jan 18, 2019, 17:11 Rory O'Donnell >> wrote: > > Hi Martin, > > Is it ok if I add to the comments section: > > #WorksFineOnJDK9 > > #WorksLikeHeavenOnJDK11 > > Rgds,Rory > On 18/01/2019 14:42, Martin Grigorov wrote: > > Hi Rory, > > I've created https://issues.jboss.org/browse/WELD-2559 for the issue >>> with > JBoss Weld. > > We would like to be listed at [1]! > Contact name: Apache Wicket team (if it has to be a single person then: > Martin Grigorov) > Mailing list: dev@wicket.apache.org > CIs: > - https://ci.apache.org/builders/wicket-branch-8.x (Wicket 8.x built > against Java 8) > - https://ci.apache.org/builders/wicket-master (Wicket 9.x built >>> against > Java 11) > - https://ci.apache.org/builders/wicket-master-java12 (Wicket 9.x >>> built > against Java 12) > - https://ci.apache.org/builders/wicket-master-java13 (Wicket 9.x >>> built > against Java 13) > > Please let us know if anything else is needed from our end! > > Kind regards, > Martin > > On Fri, Jan 18, 2019 at 3:03 PM Rory O'Donnell < >>> rory.odonn...@oracle.com> > wrote: > >> Hi Martin, >> >> I haven't seen or know of the issue you mentioned below ? >> >> I send out email every 2-3 weeks depending on contents of the builds, >> example attached. >> I try to highlight significant changes in the builds, allowing you to >> decide if you might want >> to test with a particular build. We don't expect you to test every >>> build, >> it's entirely up to you. >> If you would like us to list your project on the Quality Outreach wiki >> [1] , can you provide a >> >> contact name , mailing list (dev@wicket.apache.org) , let us know the >> status of testing JDK 8, >> >> JDK 11,JDK 12/JDK 13 EA builds and finally a CI if possible ? >> >> Rgds,Rory >> >> [1] https://wiki.openjdk.java.net/display/quality/Quality+Outreach >> On 18/01/2019 08:08, Martin Grigorov wrote: >> >> Hi Dalibor, Rory, >> >> Thank you for inviting us in this initiative! >> We, the Apache Wicket team, will be glad to help by testing Wicket >>> with >> latest OpenJDK builds! >> Please use dev@wicket.apache.org for further communication. >> >> I've just tested Wicket build with openjdk-12-ea+28_linux-x64 >> and openjdk-13-ea+4_linux-x64 and the only problem is: >> >> >> [ERROR] testPropagationAllHybrid Time elapsed: 0.001 s <<< ERROR! >> org.jboss.weld.exceptions.WeldException: WELD-001524: Unable to load >> proxy class for bean Implicit Bean [javax.enterprise.inject.Instance] >>> with >> qualifiers [@Default] with class interface >>> javax.enterprise.inject.Instance >> using classloader >>> jdk.internal.loader.ClassLoaders$AppClassLoader@1b6d3586 >> Caused by: org.jboss.weld.exceptions.WeldException: WELD-001524: >>> Unable >> to load proxy class for bean Implicit Bean >> [javax.enterprise.inject.Instance] with qualifiers [@Default] with >>> class >> interface javax.enterprise.inject.Instance using classloader >> jdk.internal.loader.ClassLoaders$AppClassLoader@1b6d3586 >> Caused by: java.lang.NoClassDefFoundError: Could not initialize class >> org.jboss.weld.util.bytecode.ClassFileUtils >> >> 12 tests in wicket-cdi module fail with this error. I guess we need to >> update JBoss Weld dependency. >> We will investigate but if you already know about this problem please >> share it with us! >> >> Kind regards, >> Martin >> >> On Wed, Jan 16, 2019 at 5:57 PM Dalibor Topic < >>> dalibor.to...@oracle.com> >> wrote: >> >>> Hi Martin, >>> >>> As part
Re: Future releases and random thoughts
Hi, On Sun, Jan 20, 2019 at 9:49 PM Andrea Del Bene wrote: > Hi, > > I think it's time to share some ideas about future releases and > developments. Here we go: > > - Wicket 8 and 7: I see we have a decent amount of changes targeted for > 8.3 > +1 to release 8.3.0 > ( > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310561=12344559). > > This is not the case for version 7.x, which doesn't have yet many issues > solved for the next version 7.11.0 > ( > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310561=12344758). > > Should we consider to release 8.3 and 7.11.0 or do you think we'd better > wait for the 7.x version to reach a "critical mass" of changes? > +1 to release 7.11.0 because of the update of commons-fileupload to 1.4 > > - Wicket 9: after we close "Wicket-6563 page store implementation" > (https://github.com/apache/wicket/pull/283) I think we could consider to > release the first milestone for Wicket 9. Sounds good to you? > +1 > > Speaking of future developments for Wicket 9, I've got (so far) a couple > of nice-to-have: > > - Use Java modularization (project Jigsaw): we should work to fully > embrace the new modularization framework. If I remember correctly Martin > has done some work with automatic modules but I can't find the exact > commit at the moment. > I cannot find it either! Somehow it got lost! http://branchandbound.net/blog/java/2017/12/automatic-module-name/ - this article explains the required changes. But apart from this minimal change I am not sure we should go fully Jigsaw. Many libraries still do not support Java 9 modules - https://blog.frankel.ch/hard-look-state-java-modularization/ Servlet specification is not updated to make use of Jigsaw and the web containers do not make use of it. > > - Dismiss utility classes Time and Duration: Wicket still heavily use a > couple of classes from package org.apache.wicket.util.time: Time and > Duration. These classes are virtually equivalent to java.time.Instant > and java.time.Duration. I'm aware that this is not a trivial task and > it's quite delicate, but I'd really like to not depend on custom code > for tasks like time and dates that are well supported by Java. For those > who are interested I've started to make some experiment with this task > and the results are very encouraging as most of the changes are in-place > replacements of the old classes with the standard entities. You can find > the code here: https://github.com/bitstorm/wicket/tree/remove-time-utils +1 if the migratiin is easy The Wicket classes should stay as deprecated for the lifetime of 9.x though > > > That's all, let me know what do you think! > >
