[
https://issues.apache.org/jira/browse/WICKET-7029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17699511#comment-17699511
]
ASF GitHub Bot commented on WICKET-7029:
----------------------------------------
timtebeek commented on code in PR #556:
URL: https://github.com/apache/wicket/pull/556#discussion_r1133573194
##########
pom.xml:
##########
@@ -119,7 +119,8 @@
<module>wicket-native-websocket</module>
<module>wicket-bean-validation</module>
<module>wicket-user-guide</module>
- </modules>
+ <module>wicket-migration</module>
Review Comment:
Open to adopt this as requested, although I'd though to sketch how we
typically structure migrations. For comparison we also support [migrations
through major versions of
Spring](https://github.com/openrewrite/rewrite-spring/tree/main/src/main/resources/META-INF/rewrite),
which are all in the same module as separate yaml files, which are chained
together to support a migration from whatever version users are using.
If we were to adopt individual modules per major version, those modules
would then likely have a dependency chain running through them, with likely no
more than a yaml file and perhaps a few recipes per module. That could also be
managed with a package within a single migration module.
Open to adopt the structure as suggested, but if you were to ask me such a
distinction isn't necessary right now. So whatever you then think is best given
the above, and your own preferences.
> Add migration recipes to Wicket 10
> ----------------------------------
>
> Key: WICKET-7029
> URL: https://issues.apache.org/jira/browse/WICKET-7029
> Project: Wicket
> Issue Type: New Feature
> Affects Versions: 10.0.0
> Reporter: Tim te Beek
> Priority: Minor
> Labels: migration
>
> The [Migration to Wicket
> 10.0|https://cwiki.apache.org/confluence/display/WICKET/Migration+to+Wicket+10.0]
> guide contains a number of breaking changes, that users will have to adopt.
> Examples include merging `wicket-http2` into `wicket-core`, and the
> associated package change of `PushHeaderItem` to
> `org.apache.wicket.markup.head.http2`. And while understandably necessary,
> these nonetheless can be a hurdle for users to adopt.
> To help users adopt Wicket 10 and the associated upgrade to Java 17 and
> Servlet 5+ I propose to add a module containing [OpenRewrite migration
> recipes|https://docs.openrewrite.org/]. For those unfamiliar: OpenRewrite
> allows you to define migration steps either through Yaml or with Java
> visitors, and compose these steps to achieve larger migrations. Such
> migrations have been [applied to Wicket
> before,|https://github.com/apache/wicket/pull/546] but they can also be
> defined and distributed for Apache Wicket users.
> As a recent example, migration recipes have been [added to Axon
> Framework|https://developer.axoniq.io/w/upgrading-to-axon-framework-4.7-automated].
> In practice that comes down to the following code changes, which also
> include instructions on their use:
> [https://github.com/AxonFramework/AxonFramework/pull/2597/files]
> Wicket 10 migration recipes can include a number of existing recipes that
> help modernize applications:
> # [Use lambdas where
> possible|https://docs.openrewrite.org/reference/recipes/java/cleanup/uselambdaforfunctionalinterface]
> # [Migrate to Jakarta EE
> 9|https://docs.openrewrite.org/reference/recipes/java/migrate/jakarta/javaxmigrationtojakarta]
> # [Migrate to Java
> 17|https://docs.openrewrite.org/reference/recipes/java/migrate/upgradetojava17]
> The Wicket 10 specific recipes can reuse common building blocks such as
> ChangeType to adopt package name changes, and RemoveDependency to remove
> `wicket-http2`.
> Technically this wouldn't have to be very difficult initially, even more so
> when the goal is to assist a migration rather than to achieve a complete
> migration. The Axon Framework migration can serve as a template, and I'm
> happy to provide guidance.
> Would this be something worth adding to Apache Wicket?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
