Re: javax.servlet -> jakarta.servlet

[Volker Lamp <vl...@apache.org>]

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 5.7.0 migration tool would be useful for Tapestry users to migrate their own code.

I'm not a Gradle expert, but willing to give it a shot. Will let you know if I come up with anything useful. Will also let you know if I get stuck so the wise guys can hopefully help me out :)

[1] https://blogs.eclipse.org/post/mike-milinkovich/jakarta-ee-9-delivers-big-bang

Volker

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org

Re: javax.servlet -> jakarta.servlet

["Thiago H. de Paula Figueiredo" <th...@gmail.com>]

On Sat, Jul 1, 2023 at 10:05 AM Volker Lamp <vl...@apache.org> 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 with 'jakarta'. Making use of with 'features' and 'capabilities' I got it to compile nicely. So far so good.

Awesome! Thanks! I'm looking forward to playing with it locally!

>
> What I'm stuck with now are missing method implementations. Tapestry's code base ist against servlet-api 3.0.1, but the jakarta namespace doesn't appear before jakarta.servlet-api:5.0.0. Here is an example. Tapestry's BufferedGZipOutputStream class extends jakarta.servlet.ServletOutputStream which has a setWriteListener(jakarta.servlet.WriteListener) method (introduced in servlet-api 3.1, by the way).
>
> For this particular case, identified by a compile error, I guess I could add an implementation of that method by calling sed or a similar tool. And that code would be in build.gradle which is clumsy especially if the implementation is more than a few lines of code. And then I would repeat the same thing for all abstract methods that were added since servlet-api 3.0.1? Probably not.

So I guess, after 5.8.3, it will be time to go to 5.9.0 and require
Servlet API 3.1 and do the changes needed for Tapestry to work with
it. :)

> Unless somebody else has a better idea, my preference for the way ahead would be to switch to Jakarta EE 9 and some point rather than running in parallel.

Since the work is already mostly done if we go through the Servlet API
3.1 upgrade route, I vote for keeping both javax.servlet and
jakarta.servlet options for some time. I believe it's not feasible to
expect the current Tapestry users want or are able to upgrade to
Jakarta EE 9 and I really don't want them stranded without the latest
Tapestry bufixes and improvements.

> As this would break backward compatibility, we would have to think about how than can be communicated in the best way, including the possibility of calling it Tapestry 6? I would also be ok with sticking with Tapestry 5 even though it's a breaking change. We've done it before, and even though it is inconvenient for users it also provides benefit for users.

I consider that Tapestry 5 is the project name. Tapestry 5.8, for
example, according to my thinking, is major version 8 of Tapestry 5.
From a historical perspective, I'd say that Tapestry 6 would be a
non-recommended idea, as Tapestry 5 retains some concepts but it's a
complete, non-backward rewrite from Tapestry 4, which isn't backward
compatible with 3, and so on. I think it would be bad PR. In
hindsight, Tapestry 5 should have had a different name when it was
first introduced. Same for Tapestry-IoC, that many people think needs
Tapestry-the-web-framework (i.e. tapestry-core and tapestry-http) to
work, and that's incorrect due to its misleading name.

Cheers!

>
> Keen to hear your thoughts.
>
> Thanks,
>
> Volker
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>


-- 
Thiago

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org

Re: javax.servlet -> jakarta.servlet

[Volker Lamp <vl...@apache.org>]

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 got it to compile nicely. So far so good.

What I'm stuck with now are missing method implementations. Tapestry's code base ist against servlet-api 3.0.1, but the jakarta namespace doesn't appear before jakarta.servlet-api:5.0.0. Here is an example. Tapestry's BufferedGZipOutputStream class extends jakarta.servlet.ServletOutputStream which has a setWriteListener(jakarta.servlet.WriteListener) method (introduced in servlet-api 3.1, by the way).

For this particular case, identified by a compile error, I guess I could add an implementation of that method by calling sed or a similar tool. And that code would be in build.gradle which is clumsy especially if the implementation is more than a few lines of code. And then I would repeat the same thing for all abstract methods that were added since servlet-api 3.0.1? Probably not.

Unless somebody else has a better idea, my preference for the way ahead would be to switch to Jakarta EE 9 and some point rather than running in parallel. As this would break backward compatibility, we would have to think about how than can be communicated in the best way, including the possibility of calling it Tapestry 6? I would also be ok with sticking with Tapestry 5 even though it's a breaking change. We've done it before, and even though it is inconvenient for users it also provides benefit for users.

Keen to hear your thoughts.

Thanks,

Volker

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org

Re: javax.servlet -> jakarta.servlet

["Thiago H. de Paula Figueiredo" <th...@gmail.com>]

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 they don't have Servlet API dependencies and we should
avoid creating new artifacts for them). If we can find a way of doing
that, that's the ideal solution. I was thinking about how we could do
it and I reached a dead end, not finding a good solution for
implementing that. If the very talented Tapestry team manages to do
it, I'll be very happy to be proven wrong. :) Of course, anything I
can help, I'll do it, also very happily.

Thanks Volker for starting the work on this!

On Tue, Apr 11, 2023 at 5:07 PM Volker Lamp <vl...@apache.org> wrote:
>
> 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 filters the source
> > tree in place as a separate gradle step. If the sources are updated in
> > place, a cleanup mechanism will be needed to restore the working copy to
> > its unmodified state between builds. Internally we use the Team City
> > swabra plugin to accomplish that goal.
>
> I agree. A temporary copy of the sources should be created, leaving the original sources untouched. The copy mechanism would replace the 'javax' package names with their 'jakarta' equivalents. The target directory of that operation would either be somewhere within the build directory (so that it would be captured by the regular 'clean' task) or in a separate source directory, next to 'src' (in which case the clean task would have to be extended to capture that directory).
>
> As far as the Gradle build script is concerned, we could take the same approach, i.e. creating a copy of build.gradle with the dependencies replaced accordingly, and subsequently triggering another build (not sure if there is a way in Gradle to invoke another gradle build from within a build?) Alternatively, we'd have to enhance the existing build.gradle with logic for the jakarta-ee-9 compatible sources. If we do the latter it is probably a good idea to leverage some of the newer Gradle DSL features in order to break up the build logic in smaller bites that would be easier to digest.
>
> As far as collaboration is concerned, I've just created a branch named TAP5-2741. Feel free to issue pull requests against it.
>
> Thank you,
>
> Volker
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>


-- 
Thiago

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org

Re: javax.servlet -> jakarta.servlet

[Volker Lamp <vl...@apache.org>]

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 filters the source 
> tree in place as a separate gradle step. If the sources are updated in 
> place, a cleanup mechanism will be needed to restore the working copy to 
> its unmodified state between builds. Internally we use the Team City 
> swabra plugin to accomplish that goal.

I agree. A temporary copy of the sources should be created, leaving the original sources untouched. The copy mechanism would replace the 'javax' package names with their 'jakarta' equivalents. The target directory of that operation would either be somewhere within the build directory (so that it would be captured by the regular 'clean' task) or in a separate source directory, next to 'src' (in which case the clean task would have to be extended to capture that directory).

As far as the Gradle build script is concerned, we could take the same approach, i.e. creating a copy of build.gradle with the dependencies replaced accordingly, and subsequently triggering another build (not sure if there is a way in Gradle to invoke another gradle build from within a build?) Alternatively, we'd have to enhance the existing build.gradle with logic for the jakarta-ee-9 compatible sources. If we do the latter it is probably a good idea to leverage some of the newer Gradle DSL features in order to break up the build logic in smaller bites that would be easier to digest.

As far as collaboration is concerned, I've just created a branch named TAP5-2741. Feel free to issue pull requests against it.

Thank you,

Volker

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org

Re: javax.servlet -> jakarta.servlet

[David Taylor <da...@extensiatech.com>]

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 might be to create a task that filters the source 
tree in place as a separate gradle step. If the sources are updated in 
place, a cleanup mechanism will be needed to restore the working copy to 
its unmodified state between builds. Internally we use the Team City 
swabra plugin to accomplish that goal.

David

On 4/11/2023 11:29 AM, Volker Lamp wrote:
> 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 5.7.0 migration tool would be useful for Tapestry users to migrate their own code.
>
> I'm not a Gradle expert, but willing to give it a shot. Will let you know if I come up with anything useful. Will also let you know if I get stuck so the wise guys can hopefully help me out :)
>
> [1] https://blogs.eclipse.org/post/mike-milinkovich/jakarta-ee-9-delivers-big-bang
>
> Volker
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org