On Tue, May 7, 2019 at 7:33 PM Mark Struberg <strub...@yahoo.de.invalid> wrote:
> Hi folks! > > Yes, I'm right now playing with it. > For a little more background and overview I've written up a blog post: > > https://struberg.wordpress.com/2019/05/06/the-way-forward-for-jakartaee-packages/ > > I've also already started to migrate a few spec packages. > The current work in progress is available here: > https://svn.apache.org/repos/asf/geronimo/specs/branches/jakarta/ > > I've already test-migrated over Apache OpenWebBeans CDI container. > Of course with TCK and servlet integration disabled for now as Arquillian > and Tomcat first needs to be ported. > https://github.com/struberg/openwebbeans/tree/jakarta > > I'm right now tinkering with Tomcat. > And boy, tomcat has way more dependencies than I'd like. > And it would help if it would finally be migrated to use Maven, but I > spare you that ;) > > As soon as I've something decently working then I'll share! > Just so that things are clear, I think I am against any jakarta.* related changes in Tomcat 9. It will stay on JakartaEE 8 no matter what, so it can use javax.* and it should stay that way since this means guaranteed zero impact for users. As is customary, the next major Tomcat version would however have support for the next relevant specifications, so that in turn would have to be jakarta.* (unless things change). I am not so sure this next version would need dual support at all, but this is completely undecided at this point. And I agree with Mark (T) that there are too many unknowns and it's too early to make a decision. Rémy > > LieGrue, > strub > > > Am 07.05.2019 um 14:09 schrieb Rémy Maucherat <r...@apache.org>: > > > > On Tue, May 7, 2019 at 12:31 PM Mark Thomas <ma...@apache.org> wrote: > > > >> On 07/05/2019 08:05, Rémy Maucherat wrote: > >>> Hi, > >>> > >>> Background information: > >>> https://eclipse-foundation.blog/2019/05/03/jakarta-ee-java-trademarks/ > >>> > >>> So this is obviously a large breaking change. While there are plenty of > >>> options, there is a simple one too: > >>> - Maintain a Tomcat 9.x "forever" with Servlet 4.0. As a result, all > the > >>> APIs in Tomcat 9 can remain javax.* and users with "old" applications > >> will > >>> still have an up to date fully compatible container for them. > >>> - Have a Tomcat 10 with all API packages renamed to jakarta.*, which > >> would > >>> provide a container for users who want to move to the new > "incompatible" > >>> Jakarta specifications. > >>> > >>> This way, there's an appropriate container for everyone. Mark Struberg > >>> proposed more elaborate strategies using classloader tricks on the ASF > >>> members list, but I'm not sure this is even needed for Tomcat. > >>> > >>> Overall, the impact for Tomcat seems rather minimal given the maturity > of > >>> Tomcat and its expected support lifecycle for 9.x. > >>> > >>> Comments ? > >> > >> I think it is good we are thinking about options but too early to settle > >> on any one solution. The solution we adopt is going to be largely > >> dependent on what the API projects at Eclipse decide to do. > >> > >> Rather than announcing a solution, how about we announce that we will > >> > > > > I agree, it is too early to decide and announce. Still, discussion is > fine > > (IMO) and unless the announced Jakarta change ends up not happening. > We'll > > indeed see what happens at Jakarta. > > > > > >> continue to support the javax.* APIS (Servlet 4.0, JSP 2.3, EL 3.0, > >> WebSocket 1.1 and JASPIC 1.1) until at least 31 Dec 2030*. Note: that > >> means supporting all the older versions of those specs as well. Exactly > >> how we do that is TBD. Extending Tomcat 9 support to the end of 2030 is > >> just one possible option. > >> > > > > +1, I was also thinking about "2030 at least" when I wrote "forever" > > because it makes for a nice impressive announcement ! > > > > > >> > >> Mark > >> > >> * Insert date of choice here. I picked first Tomcat 9 release + 10 years > >> for typical support period + 5 years extension and rounded to the end of > >> the year. > >> > > > > Rémy > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
