On Sat, Jul 1, 2023 at 10:05 AM Volker Lamp wrote:
> Hi guys,
Hello!
> A quick update and a request for help and opinions about my progress.
>
> So I got working what I thought was a good approach: a Gradle convention
> plugin that copies the Java sources whilst replacing the 'javax' imports
Hi guys,
A quick update and a request for help and opinions about my progress.
So I got working what I thought was a good approach: a Gradle convention plugin
that copies the Java sources whilst replacing the 'javax' imports with
'jakarta'. Making use of with 'features' and 'capabilities' I
Hello, everyone!
I first proposed trying to find some way to have the same sources
generating both javax and jakarta versions of the Tapestry
projects/artifacts/JARs that actually use them (don't forget about
Tapestry-IoC, Plastic, Commons, tapestry-json, etc, which wouldn't be
touched, since
Hi David
> A gradle plugin is not a bad idea and would be relatively
> straightforward to implement. We have developed many gradle plugins over
> the years and are open to contributing to that effort.
Excellent. Help is always welcome.
> The simplest approach might be to create a task that
Hello all,
I am glad to hear there is interest in moving forward on the migration.
A gradle plugin is not a bad idea and would be relatively
straightforward to implement. We have developed many gradle plugins over
the years and are open to contributing to that effort.
The simplest approach
Hello all,
As time progresses it becomes more urgent we tackle this.
As I understand the Big Bang [1], it's actually just updating the package names
indeed.
In my opinion, doing it all in Gradle would be the way to go for the Tapestry
code base. Probably writing a Gradle plugin. The Tapestry
Hi Thiago,
I haven't looked it up in detail, but if it's just the package names, 1:1
matchable classes, and the Servlet API dependency, and adapting Tapestry
code with default methods, your idea might be the best/easiest one.
Automating the process of a parallel Jakarta-based Jar would minimize
On Sat, Jul 23, 2022 at 6:08 AM Andrus Adamchik wrote:
> Hi folks,
Hello, Andrus and the dev Tapestry mailing list membeers!
> As you probably know, JavaEE has been EOL'd for some time, and everyone is
> slowly moving to JakartaEE. And this requires an entirely new build of every
>
We're not using Tomcat, but it appears so.
For Jetty, version 11 is required to support Jakarta, which is Java 11+
only.
That's one more reason to keep 5.8 around and backport as long as
reasonably possible.
On Mon, Jul 25, 2022 at 10:11 PM Volker Lamp wrote:
> +1 for a clean cut / move to
+1 for a clean cut / move to jakarta with Tapestry release 5.9.
I guess this implies upgrading from Java Servlet 3.0 to Jakarta Servlet 5.0.
Would this again imply Tomcat 10.+ is required to run Tapestry?
> Am 23.07.2022 um 15:36 schrieb David Taylor :
>
> Hi everyone,
>
> We have a similar
Hi everyone,
We have a similar requirement since we are looking to make the jump to
Spring Boot 3.0 and Hibernate 6.1 which require Jakarta EE 9 and Java
17. Thanks to everyone's hard work, we have a very solid release that
made it easy to move to Java 17. The transition to Jakarta EE is
Hi Andrus!
Personally, I would prefer a hard cut with a minor version bump to 5.9 for
a Jakarta-only Tapestry with 5.8 remaining JavaEE, instead of creating
additional projects like tapestry-http-jakarta.
Essential features, bug fixes, etc., should be backported to 5.8 for a
migration phase to
12 matches
Mail list logo
