You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Andrea Del Bene <an...@gmail.com> on 2026/01/31 18:49:17 UTC
Master branch set for Wicket 11
Hi!
I've set master branch to start working on Wicket 11. I've set java 21
as codebase version and I updated Spring and Junit respectively to
version 7 and 6. The new branch wicket-10.x will host the code for
Wicket 10. Github CI are ok for Java 21 and 25, but apache CI needs to
update Java to 21.
Please let me know if everything is ok with this.
Thank you!
Re: Master branch set for Wicket 11
Posted by Korbinian Bachl via dev <de...@wicket.apache.org>.
I already know ;)
but thx for update on this
Best,
KB
----- Ursprüngliche Mail -----
> Von: "Ernesto Reinaldo Barreiro" <re...@gmail.com>
> An: "dev" <de...@wicket.apache.org>
> Gesendet: Freitag, 30. Oktober 2026 17:37:42
> Betreff: Re: Master branch set for Wicket 11
> Hi,
>
> On Wed, Feb 4, 2026 at 6:38 AM Korbinian Bachl <
> korbinian.bachl@whiskyworld.de> wrote:
>
>> Hi all,
>>
>> I had a closer look at what it would mean to base Wicket 11 Ajax on htmx,
>> and I wanted to share some early thoughts and open questions.
>>
>> A possible technical starting point could be something like a
>> HtmxPartialPageUpdate extends PartialPageUpdate,
>> since Wicket already funnels Ajax rendering through PartialPageUpdate.
>> Conceptually, that feels like the right extension point.
>>
>> However, I’m currently unclear how Wicket would reliably detect an htmx
>> request versus a regular request.
>>
>> According to the htmx documentation (https://htmx.org/docs/#requests)
>> htmx issues regular HTTP requests (GET/POST/etc.) and identifies itself
>> via a fixed set of request headers.
>> As far as I understand, these headers cannot be freely customized (and how
>> do we differ from our "wicket htmx" requests and some of the implementing
>> developer requests?).
>>
>> In contrast, Wicket Ajax currently relies heavily on its own custom
>> headers and the AjaxRequestTarget abstraction to clearly distinguish Ajax
>> requests from normal ones and to control the response format and
>> client-side processing.
>>
>> Another structural concern is partial page updates.
>> Wicket allows updating an arbitrary number of components per request. To
>> achieve the same with htmx, hx-swap-oob would likely be required almost
>> everywhere. While technically feasible, this would fundamentally change how
>> responses are rendered and composed.
>>
>> On top of that, there is the whole ecosystem of:
>>
>> Ajax behaviors and event bindings
>>
>> AjaxFormSubmitBehavior and related form-processing semantics
>>
>> Even if all of this could be reimplemented on top of htmx, there is a
>> bigger compatibility question.
>>
>> How would existing code—especially from wicketstuff, third-party
>> components, and private component registries—continue to work?
>>
>> A lot of existing components rely directly or indirectly on:
>>
>> Wicket.Ajax client-side code
>> the XML-based Ajax response format
>> JavaScript callbacks injected via AjaxRequestTarget
>>
>> Requiring all of that to be rewritten would be a very disruptive change
>> for the ecosystem.
>>
>> This makes me wonder whether a more incremental approach might be
>> preferable.
>>
>> For example:
>>
>> First, remove the dependency on jQuery and modernize the existing Wicket
>> Ajax JavaScript.
>>
>
> This is already implemented in Wicket 11.
>
>
>> Then evaluate the size, complexity, and responsibilities of the remaining
>> Wicket JS layer.
>> Based on that, explore htmx more deeply and evaluate whether a
>> compatibility layer (some form of Wicket.Ajax glue on top of htmx) could
>> realistically preserve backward compatibility.
>>
>> That might give a clearer picture of how much change is actually needed,
>> and where htmx genuinely helps versus where it introduces new challenges.
>>
>> I’m very interested in hearing thoughts on whether such a staged approach
>> would make sense, or if people see a cleaner path forward that I’m missing.
>>
>> Best,
>> Korbinian
>>
>>
>>
>>
>>
>>
>> ----- Ursprüngliche Mail -----
>> > Von: "Martijn Dashorst"
>> > An: "dev" <de...@wicket.apache.org>
>> > Gesendet: Montag, 2. Februar 2026 16:15:39
>> > Betreff: Re: Master branch set for Wicket 11
>>
>> > I have no concrete plans, but a wishful thinking list:
>> >
>> > I am considering a marriage between HTMX for client side and Wicket for
>> > backend. But nothing concrete (or even in a proof of concept, just an
>> idea
>> > in my head).
>> >
>> > There are some hurdles to overcome with that approach:
>> > - wicket component identifiers and generated markup ids will prevent most
>> > of the currently used morphing algorithms to work properly, and probably
>> > also be a blocker for htmx
>> > - using htmx as front end assumes htmx is in the lead for issuing
>> requests
>> > to the backend and wants to have a HTML response (which is not Wicket's
>> way)
>> > - using hx-swap="append" or similar is not compatible with wicket's
>> > listview/dataview components that render everything
>> > - using idiomorph for replacing markup in an ajax swap will probably not
>> > work due to the new markup ids for components
>> >
>> > I also want to look to modernise the API and internals, using builders,
>> > automatic parameter resolving similar to JAXRS, etc.
>> >
>> > Make the renderer easier to embed in JAXRS
>> >
>> > Make Wicket and Quarkus work better together (and native compilation)
>> >
>> > Make Wicket's stateless support first class.
>> >
>> > And probably more than I can manage :D
>> >
>> > Martijn
>> >
>> >
>> >
>> > On Mon, Feb 2, 2026 at 1:22 PM Korbinian Bachl <
>> > korbinian.bachl@whiskyworld.de> wrote:
>> >
>> >> Hi,
>> >>
>> >> is there any kind of ideas/ roadmap already?
>> >>
>> >> What serlvet level ist planned? 6.0? or 6.1?
>> >>
>> >> Will CDI be seen as core requirement?
>> >>
>> >> What about jQuery dependency and ajax?
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> ----- Ursprüngliche Mail -----
>> >> > Von: "Andrea Del Bene"
>> >> > An: "dev" <de...@wicket.apache.org>
>> >> > Gesendet: Samstag, 31. Januar 2026 19:49:17
>> >> > Betreff: Master branch set for Wicket 11
>> >>
>> >> > Hi!
>> >> >
>> >> > I've set master branch to start working on Wicket 11. I've set java
>> 21
>> >> > as codebase version and I updated Spring and Junit respectively to
>> >> > version 7 and 6. The new branch wicket-10.x will host the code for
>> >> > Wicket 10. Github CI are ok for Java 21 and 25, but apache CI needs to
>> >> > update Java to 21.
>> >> > Please let me know if everything is ok with this.
>> >> >
>> >> > Thank you!
>> >>
>> >
>> >
>> > --
>> > Become a Wicket expert, learn from the best: http://wicketinaction.com
>>
>
>
> --
> Regards -
> Ernesto Reinaldo Barreiro
> Apache Wicket Committer
> Emerging artist
> https://www.instagram.com/reinaldo.barreiro.art/
Re: Master branch set for Wicket 11
Posted by Ernesto Reinaldo Barreiro <re...@gmail.com>.
Hi,
On Wed, Feb 4, 2026 at 6:38 AM Korbinian Bachl <
korbinian.bachl@whiskyworld.de> wrote:
> Hi all,
>
> I had a closer look at what it would mean to base Wicket 11 Ajax on htmx,
> and I wanted to share some early thoughts and open questions.
>
> A possible technical starting point could be something like a
> HtmxPartialPageUpdate extends PartialPageUpdate,
> since Wicket already funnels Ajax rendering through PartialPageUpdate.
> Conceptually, that feels like the right extension point.
>
> However, I’m currently unclear how Wicket would reliably detect an htmx
> request versus a regular request.
>
> According to the htmx documentation (https://htmx.org/docs/#requests)
> htmx issues regular HTTP requests (GET/POST/etc.) and identifies itself
> via a fixed set of request headers.
> As far as I understand, these headers cannot be freely customized (and how
> do we differ from our "wicket htmx" requests and some of the implementing
> developer requests?).
>
> In contrast, Wicket Ajax currently relies heavily on its own custom
> headers and the AjaxRequestTarget abstraction to clearly distinguish Ajax
> requests from normal ones and to control the response format and
> client-side processing.
>
> Another structural concern is partial page updates.
> Wicket allows updating an arbitrary number of components per request. To
> achieve the same with htmx, hx-swap-oob would likely be required almost
> everywhere. While technically feasible, this would fundamentally change how
> responses are rendered and composed.
>
> On top of that, there is the whole ecosystem of:
>
> Ajax behaviors and event bindings
>
> AjaxFormSubmitBehavior and related form-processing semantics
>
> Even if all of this could be reimplemented on top of htmx, there is a
> bigger compatibility question.
>
> How would existing code—especially from wicketstuff, third-party
> components, and private component registries—continue to work?
>
> A lot of existing components rely directly or indirectly on:
>
> Wicket.Ajax client-side code
> the XML-based Ajax response format
> JavaScript callbacks injected via AjaxRequestTarget
>
> Requiring all of that to be rewritten would be a very disruptive change
> for the ecosystem.
>
> This makes me wonder whether a more incremental approach might be
> preferable.
>
> For example:
>
> First, remove the dependency on jQuery and modernize the existing Wicket
> Ajax JavaScript.
>
This is already implemented in Wicket 11.
> Then evaluate the size, complexity, and responsibilities of the remaining
> Wicket JS layer.
> Based on that, explore htmx more deeply and evaluate whether a
> compatibility layer (some form of Wicket.Ajax glue on top of htmx) could
> realistically preserve backward compatibility.
>
> That might give a clearer picture of how much change is actually needed,
> and where htmx genuinely helps versus where it introduces new challenges.
>
> I’m very interested in hearing thoughts on whether such a staged approach
> would make sense, or if people see a cleaner path forward that I’m missing.
>
> Best,
> Korbinian
>
>
>
>
>
>
> ----- Ursprüngliche Mail -----
> > Von: "Martijn Dashorst"
> > An: "dev" <de...@wicket.apache.org>
> > Gesendet: Montag, 2. Februar 2026 16:15:39
> > Betreff: Re: Master branch set for Wicket 11
>
> > I have no concrete plans, but a wishful thinking list:
> >
> > I am considering a marriage between HTMX for client side and Wicket for
> > backend. But nothing concrete (or even in a proof of concept, just an
> idea
> > in my head).
> >
> > There are some hurdles to overcome with that approach:
> > - wicket component identifiers and generated markup ids will prevent most
> > of the currently used morphing algorithms to work properly, and probably
> > also be a blocker for htmx
> > - using htmx as front end assumes htmx is in the lead for issuing
> requests
> > to the backend and wants to have a HTML response (which is not Wicket's
> way)
> > - using hx-swap="append" or similar is not compatible with wicket's
> > listview/dataview components that render everything
> > - using idiomorph for replacing markup in an ajax swap will probably not
> > work due to the new markup ids for components
> >
> > I also want to look to modernise the API and internals, using builders,
> > automatic parameter resolving similar to JAXRS, etc.
> >
> > Make the renderer easier to embed in JAXRS
> >
> > Make Wicket and Quarkus work better together (and native compilation)
> >
> > Make Wicket's stateless support first class.
> >
> > And probably more than I can manage :D
> >
> > Martijn
> >
> >
> >
> > On Mon, Feb 2, 2026 at 1:22 PM Korbinian Bachl <
> > korbinian.bachl@whiskyworld.de> wrote:
> >
> >> Hi,
> >>
> >> is there any kind of ideas/ roadmap already?
> >>
> >> What serlvet level ist planned? 6.0? or 6.1?
> >>
> >> Will CDI be seen as core requirement?
> >>
> >> What about jQuery dependency and ajax?
> >>
> >>
> >>
> >>
> >>
> >>
> >> ----- Ursprüngliche Mail -----
> >> > Von: "Andrea Del Bene"
> >> > An: "dev" <de...@wicket.apache.org>
> >> > Gesendet: Samstag, 31. Januar 2026 19:49:17
> >> > Betreff: Master branch set for Wicket 11
> >>
> >> > Hi!
> >> >
> >> > I've set master branch to start working on Wicket 11. I've set java
> 21
> >> > as codebase version and I updated Spring and Junit respectively to
> >> > version 7 and 6. The new branch wicket-10.x will host the code for
> >> > Wicket 10. Github CI are ok for Java 21 and 25, but apache CI needs to
> >> > update Java to 21.
> >> > Please let me know if everything is ok with this.
> >> >
> >> > Thank you!
> >>
> >
> >
> > --
> > Become a Wicket expert, learn from the best: http://wicketinaction.com
>
--
Regards -
Ernesto Reinaldo Barreiro
Apache Wicket Committer
Emerging artist
https://www.instagram.com/reinaldo.barreiro.art/
Re: Master branch set for Wicket 11
Posted by Korbinian Bachl <ko...@whiskyworld.de>.
Hi all,
I had a closer look at what it would mean to base Wicket 11 Ajax on htmx, and I wanted to share some early thoughts and open questions.
A possible technical starting point could be something like a
HtmxPartialPageUpdate extends PartialPageUpdate,
since Wicket already funnels Ajax rendering through PartialPageUpdate. Conceptually, that feels like the right extension point.
However, I’m currently unclear how Wicket would reliably detect an htmx request versus a regular request.
According to the htmx documentation (https://htmx.org/docs/#requests)
htmx issues regular HTTP requests (GET/POST/etc.) and identifies itself via a fixed set of request headers.
As far as I understand, these headers cannot be freely customized (and how do we differ from our "wicket htmx" requests and some of the implementing developer requests?).
In contrast, Wicket Ajax currently relies heavily on its own custom headers and the AjaxRequestTarget abstraction to clearly distinguish Ajax requests from normal ones and to control the response format and client-side processing.
Another structural concern is partial page updates.
Wicket allows updating an arbitrary number of components per request. To achieve the same with htmx, hx-swap-oob would likely be required almost everywhere. While technically feasible, this would fundamentally change how responses are rendered and composed.
On top of that, there is the whole ecosystem of:
Ajax behaviors and event bindings
AjaxFormSubmitBehavior and related form-processing semantics
Even if all of this could be reimplemented on top of htmx, there is a bigger compatibility question.
How would existing code—especially from wicketstuff, third-party components, and private component registries—continue to work?
A lot of existing components rely directly or indirectly on:
Wicket.Ajax client-side code
the XML-based Ajax response format
JavaScript callbacks injected via AjaxRequestTarget
Requiring all of that to be rewritten would be a very disruptive change for the ecosystem.
This makes me wonder whether a more incremental approach might be preferable.
For example:
First, remove the dependency on jQuery and modernize the existing Wicket Ajax JavaScript.
Then evaluate the size, complexity, and responsibilities of the remaining Wicket JS layer.
Based on that, explore htmx more deeply and evaluate whether a compatibility layer (some form of Wicket.Ajax glue on top of htmx) could realistically preserve backward compatibility.
That might give a clearer picture of how much change is actually needed, and where htmx genuinely helps versus where it introduces new challenges.
I’m very interested in hearing thoughts on whether such a staged approach would make sense, or if people see a cleaner path forward that I’m missing.
Best,
Korbinian
----- Ursprüngliche Mail -----
> Von: "Martijn Dashorst"
> An: "dev" <de...@wicket.apache.org>
> Gesendet: Montag, 2. Februar 2026 16:15:39
> Betreff: Re: Master branch set for Wicket 11
> I have no concrete plans, but a wishful thinking list:
>
> I am considering a marriage between HTMX for client side and Wicket for
> backend. But nothing concrete (or even in a proof of concept, just an idea
> in my head).
>
> There are some hurdles to overcome with that approach:
> - wicket component identifiers and generated markup ids will prevent most
> of the currently used morphing algorithms to work properly, and probably
> also be a blocker for htmx
> - using htmx as front end assumes htmx is in the lead for issuing requests
> to the backend and wants to have a HTML response (which is not Wicket's way)
> - using hx-swap="append" or similar is not compatible with wicket's
> listview/dataview components that render everything
> - using idiomorph for replacing markup in an ajax swap will probably not
> work due to the new markup ids for components
>
> I also want to look to modernise the API and internals, using builders,
> automatic parameter resolving similar to JAXRS, etc.
>
> Make the renderer easier to embed in JAXRS
>
> Make Wicket and Quarkus work better together (and native compilation)
>
> Make Wicket's stateless support first class.
>
> And probably more than I can manage :D
>
> Martijn
>
>
>
> On Mon, Feb 2, 2026 at 1:22 PM Korbinian Bachl <
> korbinian.bachl@whiskyworld.de> wrote:
>
>> Hi,
>>
>> is there any kind of ideas/ roadmap already?
>>
>> What serlvet level ist planned? 6.0? or 6.1?
>>
>> Will CDI be seen as core requirement?
>>
>> What about jQuery dependency and ajax?
>>
>>
>>
>>
>>
>>
>> ----- Ursprüngliche Mail -----
>> > Von: "Andrea Del Bene"
>> > An: "dev" <de...@wicket.apache.org>
>> > Gesendet: Samstag, 31. Januar 2026 19:49:17
>> > Betreff: Master branch set for Wicket 11
>>
>> > Hi!
>> >
>> > I've set master branch to start working on Wicket 11. I've set java 21
>> > as codebase version and I updated Spring and Junit respectively to
>> > version 7 and 6. The new branch wicket-10.x will host the code for
>> > Wicket 10. Github CI are ok for Java 21 and 25, but apache CI needs to
>> > update Java to 21.
>> > Please let me know if everything is ok with this.
>> >
>> > Thank you!
>>
>
>
> --
> Become a Wicket expert, learn from the best: http://wicketinaction.com
Re: Master branch set for Wicket 11
Posted by Martijn Dashorst <ma...@gmail.com>.
Another thing that came to me during work:
we have AutoLabelResolver, but our story for aria-describedBy and other
aria- attributes is non existent.
I'd love to expand AutoLabelResolver's story to support aria-* attributes
to be able to couple in a reusable manner two markup elements together.
Martijn
On Mon, Feb 2, 2026 at 4:15 PM Martijn Dashorst <ma...@gmail.com>
wrote:
> I have no concrete plans, but a wishful thinking list:
>
> I am considering a marriage between HTMX for client side and Wicket for
> backend. But nothing concrete (or even in a proof of concept, just an idea
> in my head).
>
> There are some hurdles to overcome with that approach:
> - wicket component identifiers and generated markup ids will prevent most
> of the currently used morphing algorithms to work properly, and probably
> also be a blocker for htmx
> - using htmx as front end assumes htmx is in the lead for issuing requests
> to the backend and wants to have a HTML response (which is not Wicket's way)
> - using hx-swap="append" or similar is not compatible with wicket's
> listview/dataview components that render everything
> - using idiomorph for replacing markup in an ajax swap will probably not
> work due to the new markup ids for components
>
> I also want to look to modernise the API and internals, using builders,
> automatic parameter resolving similar to JAXRS, etc.
>
> Make the renderer easier to embed in JAXRS
>
> Make Wicket and Quarkus work better together (and native compilation)
>
> Make Wicket's stateless support first class.
>
> And probably more than I can manage :D
>
> Martijn
>
>
>
> On Mon, Feb 2, 2026 at 1:22 PM Korbinian Bachl <
> korbinian.bachl@whiskyworld.de> wrote:
>
>> Hi,
>>
>> is there any kind of ideas/ roadmap already?
>>
>> What serlvet level ist planned? 6.0? or 6.1?
>>
>> Will CDI be seen as core requirement?
>>
>> What about jQuery dependency and ajax?
>>
>>
>>
>>
>>
>>
>> ----- Ursprüngliche Mail -----
>> > Von: "Andrea Del Bene"
>> > An: "dev" <de...@wicket.apache.org>
>> > Gesendet: Samstag, 31. Januar 2026 19:49:17
>> > Betreff: Master branch set for Wicket 11
>>
>> > Hi!
>> >
>> > I've set master branch to start working on Wicket 11. I've set java 21
>> > as codebase version and I updated Spring and Junit respectively to
>> > version 7 and 6. The new branch wicket-10.x will host the code for
>> > Wicket 10. Github CI are ok for Java 21 and 25, but apache CI needs to
>> > update Java to 21.
>> > Please let me know if everything is ok with this.
>> >
>> > Thank you!
>>
>
>
> --
> Become a Wicket expert, learn from the best: http://wicketinaction.com
>
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Re: Master branch set for Wicket 11
Posted by Martijn Dashorst <ma...@gmail.com>.
I have no concrete plans, but a wishful thinking list:
I am considering a marriage between HTMX for client side and Wicket for
backend. But nothing concrete (or even in a proof of concept, just an idea
in my head).
There are some hurdles to overcome with that approach:
- wicket component identifiers and generated markup ids will prevent most
of the currently used morphing algorithms to work properly, and probably
also be a blocker for htmx
- using htmx as front end assumes htmx is in the lead for issuing requests
to the backend and wants to have a HTML response (which is not Wicket's way)
- using hx-swap="append" or similar is not compatible with wicket's
listview/dataview components that render everything
- using idiomorph for replacing markup in an ajax swap will probably not
work due to the new markup ids for components
I also want to look to modernise the API and internals, using builders,
automatic parameter resolving similar to JAXRS, etc.
Make the renderer easier to embed in JAXRS
Make Wicket and Quarkus work better together (and native compilation)
Make Wicket's stateless support first class.
And probably more than I can manage :D
Martijn
On Mon, Feb 2, 2026 at 1:22 PM Korbinian Bachl <
korbinian.bachl@whiskyworld.de> wrote:
> Hi,
>
> is there any kind of ideas/ roadmap already?
>
> What serlvet level ist planned? 6.0? or 6.1?
>
> Will CDI be seen as core requirement?
>
> What about jQuery dependency and ajax?
>
>
>
>
>
>
> ----- Ursprüngliche Mail -----
> > Von: "Andrea Del Bene"
> > An: "dev" <de...@wicket.apache.org>
> > Gesendet: Samstag, 31. Januar 2026 19:49:17
> > Betreff: Master branch set for Wicket 11
>
> > Hi!
> >
> > I've set master branch to start working on Wicket 11. I've set java 21
> > as codebase version and I updated Spring and Junit respectively to
> > version 7 and 6. The new branch wicket-10.x will host the code for
> > Wicket 10. Github CI are ok for Java 21 and 25, but apache CI needs to
> > update Java to 21.
> > Please let me know if everything is ok with this.
> >
> > Thank you!
>
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Re: Master branch set for Wicket 11
Posted by Korbinian Bachl <ko...@whiskyworld.de>.
Hi,
is there any kind of ideas/ roadmap already?
What serlvet level ist planned? 6.0? or 6.1?
Will CDI be seen as core requirement?
What about jQuery dependency and ajax?
----- Ursprüngliche Mail -----
> Von: "Andrea Del Bene"
> An: "dev" <de...@wicket.apache.org>
> Gesendet: Samstag, 31. Januar 2026 19:49:17
> Betreff: Master branch set for Wicket 11
> Hi!
>
> I've set master branch to start working on Wicket 11. I've set java 21
> as codebase version and I updated Spring and Junit respectively to
> version 7 and 6. The new branch wicket-10.x will host the code for
> Wicket 10. Github CI are ok for Java 21 and 25, but apache CI needs to
> update Java to 21.
> Please let me know if everything is ok with this.
>
> Thank you!
Re: Master branch set for Wicket 11
Posted by Andrea Del Bene <an...@gmail.com>.
Thank you, I mean it!
On Mon, Feb 2, 2026 at 10:24 AM Martijn Dashorst <ma...@gmail.com>
wrote:
> To speak as a dutch native: good busy!
>
> Martijn
>
> On Sat, Jan 31, 2026 at 7:49 PM Andrea Del Bene <an...@gmail.com>
> wrote:
>
> > Hi!
> >
> > I've set master branch to start working on Wicket 11. I've set java 21
> > as codebase version and I updated Spring and Junit respectively to
> > version 7 and 6. The new branch wicket-10.x will host the code for
> > Wicket 10. Github CI are ok for Java 21 and 25, but apache CI needs to
> > update Java to 21.
> > Please let me know if everything is ok with this.
> >
> > Thank you!
> >
> >
>
> --
> Become a Wicket expert, learn from the best: http://wicketinaction.com
>
--
Andrea Del Bene.
Apache Wicket committer.
Re: Master branch set for Wicket 11
Posted by Martijn Dashorst <ma...@gmail.com>.
To speak as a dutch native: good busy!
Martijn
On Sat, Jan 31, 2026 at 7:49 PM Andrea Del Bene <an...@gmail.com>
wrote:
> Hi!
>
> I've set master branch to start working on Wicket 11. I've set java 21
> as codebase version and I updated Spring and Junit respectively to
> version 7 and 6. The new branch wicket-10.x will host the code for
> Wicket 10. Github CI are ok for Java 21 and 25, but apache CI needs to
> update Java to 21.
> Please let me know if everything is ok with this.
>
> Thank you!
>
>
--
Become a Wicket expert, learn from the best: http://wicketinaction.com