Yes, the first step is just trying out what we could have missed. And of course this would be tc-10.
The first quick and dirty hack is alive: https://github.com/struberg/tomcat/tree/jakarta You first need to compile the geronimo-jakarta specs locally from https://svn.apache.org/repos/asf/geronimo/specs/branches/jakarta/ Then (don't slap me!) you have to run a mvn clean install in tomcat. This will just fire up the dependency resolution for those jakarta specs missing and copy them to target/dependency/*.jar Then run a standard ant There are really dirty parts in the change. mostly around everything XAResource related. Like LocalXAConnectionFactory and DataSourceXAConnectionFactory. Attention: I'm totally tired already and I've not run any tests yet. But at least it compiles again. have fun! LieGrue, strub > Am 07.05.2019 um 20:38 schrieb Rémy Maucherat <r...@apache.org>: > > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
