Closed lkishalmi closed 8 months ago
Well, this version seems to fail on plarfom/libs.osgi
which shall generate an empty report.
The new tool has some specific handling for Java 17.
The old tool does something somehow not match any package with the following patterns info.dmtree.**, org.osgi.**
The new version does. Unfortunately osgi.cmpn-7.0.0.jar
has references some javax.servlet
classes which are not on the classpath.
Adding sigtest.public.packages=-
to the project.properties
helped, but there are other classloader issues after that.
I'm out of ideas here.
@jtulach ?
Not sure if it helps, but I think this causes the "error" in libs.osgi
:
https://github.com/eclipse-ee4j/jakartaee-tck-tools/commit/56e3e338dba7b008536f5aa13d4423179d1d4b17
If I read the summary of the commit correctly, before this commit recursive definitions like info.dmtree.**, org.osgi.**
were not handled correctly. If I'm not mistaken, only the first level was considered.
The commit was added between 1.5 and 1.6 and indeed using 1.5 I can run the sigtest generator in libs.osgi
and 1.6 fails. And for some unknown reason that also matches the fact, that NetBeans itself stayed with sigtest 1.4.
Channeling my bash deamons I came up with this list of modules that might be affected:
find . -name project.xml | xargs grep -l subpackages | cut --delimiter "/" -f 2-3
extide/libs.gradle
webcommon/libs.nashorn
java/j2ee.eclipselink
java/maven.embedder
enterprise/web.jsf12
enterprise/web.jsf20
enterprise/j2eeapis
ide/servletapi
ide/libs.lucene
ide/libs.jcodings
ide/o.apache.xml.resolver
ide/libs.snakeyaml_engine
ide/libs.xerces
ide/libs.flexmark
platform/libs.asm
platform/libs.osgi
I think 1.4 was needed to build on jdk 11. As it was "working" did'nt think on upgrading.
I'm always puzzled with sigtest as on jenkins we have issue In one there is 24 test failing: https://ci-builds.apache.org/job/Netbeans/job/netbeans-apisigcheck/lastCompletedBuild/testReport/ with ga checker we swallow them.
In both case there are a bunch of java.lang.ClassFormatError: Index out of the constant pool bounds during sig phase.
Well the last commit forces to use sigtest to generate signatures without recursion.
That behavior was fixed in the commit mentioned above, so that commit is just keeping the same wrong way of doing the things as before.
LGTM with my limited understanding
Anyone, a word? I'm about to merge this one today or tomorrow, as #7024 is depending on this one.
@matthiasblaesing thanks for your feedback!
would it make sense to open a meta issue afterwards which has a list of all mods where sig tests are turned off so that we can look that up when needed?
I've tried to upgrade Sigtest to the latest available version 1.7, and that still fails on Java 17. @mbien pionted out that there is a fork in JakartaEE TCK that could work. It did the job.
This is needed when a module is on Java 17 and exposes some API.