I just wanted to make a note that removing the annotation will also mean that the module-info.java will need to be manually managed since bnd also generated that based on the annotations.
Just FYI, - Ray On Thu, Apr 1, 2021 at 4:40 AM Jean-Louis MONTEIRO <jeano...@gmail.com> wrote: > 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 > -- *Raymond Augé* (@rotty3000) Senior Software Architect *Liferay, Inc.* (@Liferay) OSGi Fellow
