That's awesome news. I'm glad it's something that can be achieved without too much effort. I understand and buy the pragmatic approach.
But at the same time, if we can do a step forward and get even closer to being certified, that'd be great. Le jeu. 1 avr. 2021 à 10:06, Mark Thomas <ma...@apache.org> a écrit : > I've been playing with this a bit more and it appears we can simply > hard-code the "Require-Capability" header in el-api.jar.bnd > > Having taken the time to look at the actual values generated for these > API JARs, this does look like something that would be simple to maintain > manually - especially for the API JARs where adding a new use of > ServiceLoader is likely to happen fairly rarely. > > We should be able to remove the Bnd annotation in > - 10.0.x for 10.0.6 onwards > - 9.0.x for 9.0.46 onwards > > We'll certainly do this for the API JARs. I think we'll leave it in > place for the implementation JARs > > I have a few things on my TODO list at the moment but I don't see why I > shouldn't be able to get this done for the May set of releases. > > Mark > > > On 01/04/2021 08:24, Romain Manni-Bucau wrote: > > Hi, > > > > AFAIK TomEE will try to be certified and will try to not fork as much as > > possible Tomcat code so can be neat to solve it in particular when > > relatively easy: > > > > 1. compile tomcat classes with bnd as of today > > 2. run bnd to get the manifest.mf ( > > 3. post process tomcat classes to remove bnd from the .class > > 4. jar it > > > > should solve the process and does not look crazy compared to what tomcat > > already does, no? > > > > Alternative is indeed to drop bnd since the manifest is quite easy to > write > > manually or with an ant task to filter the version for tomcat case, at > > least for spec jars (it is harder for the impl but here bnd is fine). > > > > 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 jeu. 1 avr. 2021 à 09:19, Mark Thomas <ma...@apache.org> a écrit : > > > >> On 31/03/2021 20:14, Volodymyr Siedlecki wrote: > >>> Hello, > >>> > >>> It appears the TCK Signature tests will not be relaxed (see 1 & 2), > >>> and I'm wondering how Tomcat will proceed with the bnd annotation in > >>> the EL API? Will it be removed in the next release? > >> > >> Currently, there are no plans to change the Tomcat code. > >> > >> We do run the TCKs but take a pragmatic view of any failures. For > >> example, the Servlet TCK test that tests setting a context path in > >> web.xml always fails because Tomcat always overrides any such setting. > >> The Servlet spec allows this setting to be overridden but the TCK test > >> doesn't consider the possibility that a container will always do this. > >> Therefore we simply treat this as an expected failure. Full details for > >> all the TCKs we run can be found on the Wiki: > >> > >> https://cwiki.apache.org/confluence/display/TOMCAT/Jakarta+EE+TCKs > >> > >> The EL signature test failure is another example of a failure that we > >> consider can be safely ignored. > >> > >> Tomcat does not, and has not for many, many years, formally certified > >> against the Jakarta EE / Java EE TCKs. I am not aware of any user > >> request at any point in that time to complete formal certification. > >> Therefore, I expect that Tomcat will continue following its current > >> pragmatic approach to the TCKs. > >> > >> Mark > >> > >> --------------------------------------------------------------------- > >> 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 > > -- Jean-Louis
