Hi, On Tue, Apr 6, 2021 at 7:22 PM Raymond Augé <raymond.a...@liferay.com.invalid> wrote:
> Great news! I'm both sad that the annotations caused you pain (the complete > opposite was intended) and happy that you managed to work around the > problem. > > It's not by coincidence that BND uses the intermediate state of the > manifest to go between the annotations and the module info. However, I > wasn't sure that this would cover all cases particularly w.r.t. the service > loader handling. However, it appears it does. > I am not sure how exactly BND works but at [1] I see that ServiceConsumer annotation has retention policy CLASS. Would it be possible to use SOURCE instead ? This way at compile time it could be used to generate module-info.class and be discarded, i.e. the annotation won't be in the API .class 1. https://github.com/bndtools/bnd/blob/ba0bd37c2c33afe4ccfd8660b1a37b1c1ac52eaa/biz.aQute.bnd.annotation/src/aQute/bnd/annotation/spi/ServiceConsumer.java#L33 > > Sincerely, > Ray > > > On Tue, Apr 6, 2021 at 10:39 AM Mark Thomas <ma...@apache.org> wrote: > > > On 02/04/2021 13:58, Raymond Augé wrote: > > > 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. > > > > Good news. I compared the module-info.class files for the EL API jar and > > the WebSocket API jar between the 9.0.45 release (that used the > > annotation) and a current build from source (that doesn't use the > > annotation) and they are identical. On that basis I think we have a > > working solution. > > > > Mark > > > > > > > > > > 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 > > >> > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: dev-h...@tomcat.apache.org > > > > > > -- > *Raymond Augé* (@rotty3000) > Senior Software Architect *Liferay, Inc.* (@Liferay) > OSGi Fellow >
