Proposed that as well, not yet sure since means there is no more cetifiable version but let see.
Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le ven. 29 mars 2024 à 16:51, Christopher Schultz < ch...@christopherschultz.net> a écrit : > Romain, > > On 3/29/24 08:50, Romain Manni-Bucau wrote: > > Le ven. 29 mars 2024 à 13:41, Christopher Schultz < > > ch...@christopherschultz.net> a écrit : > > > >> Romain, > >> > >> On 3/29/24 03:18, Romain Manni-Bucau wrote: > >>> Side note: what I meant about ASF is that there was a help habit > between > >>> communities. I know it got "broken" (=it is no more a general real > thing) > >>> some years ago to isolate all projects (give them a total independency) > >> but > >>> I'm clearly not a fan of that, in particular when it deserves the > project > >>> but I totally respect your choice, didnt mean anything stronger than a > >> hope. > >> > >> No problem. Adding the smile made it clear you were hoping about me > >> specifically. But it wasn't clear what you were saying about the > >> (Tomcat) project itself. > >> > >>> On the method addition/ TCK: no issue since signature of the api stays > >> the > >>> same. > >>> Can break tomcat facade object design - but not a big deal for me - but > >>> clearly not tck compat. > >> > >> Okay, I'm not super familiar with the TCK process itself. I had assumed > >> that if we added arbitrary methods to the jakarta.* public interfaces, > >> we'd fail the TCK. > >> > > > > This is true but the proposal is more to comply to servlet5 U servlet 6 > > (union) API in tomcat objects. > > If ServletRequestImpl (RequestFacade mainly) has the union of methods > then > > it can run with api 5 or 6 and still repect the compliance of both in the > > same codebase. > > > > Indeed I'm only proposing it cause the diff is very low IMHO otherwise I > > agree it would be a nightmare. > > > > > >> > >> If that's not the case, then... > >> > >> If you build a patch set for Tomcat 10.1.x to re-add those methods and > >> it passes your TCK, we can apply them to 10.1 nd see if we also pass the > >> TCK. > >> > >> If it passes both, I have no objection to adding those methods back to > >> 10.1 to help-out anyone who feels strongly about supporting Servlet 5. > >> You may find that others on the team are -1 on this; I'm not sure. > >> > >> Back to practical things: if you maintain a patch set (which should be > >> fairly limited, as I asserted and you seem to agree with) that you can > >> apply in order to pass the TCK and that's neaarly all its for, then I > >> think it won't be much maintenance for you to keep that set. > >> > >> That is, if you either directly-fork Tomcat 10.1 or if your build > >> process downloads the sources, patches and builds Tomcat locally, then > >> you will pass the TCK and everyone is happy. > >> > > > > The fork part is the unhappy part, not because of the work but because: > > > > * It breaks security scans > > * It breaks change tracking and needs adjustments (for tomcat you try to > > limit the diff between branches but as soon the branch is outside the > > project it will be more complicated and a change can break the downstream > > project more easily) > > * It requires yet another release cycle outside of the official project > > * It confuses end users > > * It makes it impossible for users to upgrade Tomcat without a release of > > the fork - what is possible in embedded TomEE or other projects > > > > This is why I was looking for another compromise. > > Could another compromise be "TomEE ignores Servlet 5 and just goes > directly to Servlet 6"? That seems to be what Rémy is recommending > because he obviously has no affection for Servlet 5 :) > > -chris > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
