On Mon, Jan 21, 2019 at 10:24 AM Martin Grigorov <mgrigo...@apache.org> wrote:
> Hi, > > On Sun, Jan 20, 2019 at 9:49 PM Andrea Del Bene <an.delb...@gmail.com> > 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&version=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&version=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. > Re-added it! > > 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! >> >>
