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
