Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-tck-dev] Some observations / action items using sigtest-maven-plugin in Batch standlone TCK


On 12/2/21 11:23 AM, Scott Kurz wrote:

As I mentioned in the TCK call yesterday, I was experimenting using the sigtest-maven-plugin (hosted at https://github.com/jtulach/netbeans-apitest, referenced from Scott M's earlier emails e.g.:  https://www.eclipse.org/lists/jakartaee-tck-dev/msg01424.html)
in the Batch standalone TCK, as the CDI TCK is doing:   https://github.com/eclipse-ee4j/cdi-tck/blob/master/doc/reference/src/main/asciidoc/sigtest.asciidoc

FYI, for Platform TCK signature generation, we are currently using the com.sun.tdk.signaturetest.Main class in the above mentioned netbeans-apitest tool.  We are also using the `-BootCp 11` option when generating the signature test files on JDK11 (see build_signatures.sh#L97).  The se11 signature files that we are generating should work on both JDK


Let me stop and share a couple observations:

FEATURE REQUESTS

I opened a couple "feature requests" as draft PRs, (since there's no issues tab on the GitHub  repo):

1. https://github.com/jtulach/netbeans-apitest/pull/8 -    Expose "-IgnoreJDKClass" via Maven, overlapping the Jakarta discussion: eclipse-ee4j/jakartaee-tck#156 ,   making it easier to use a single signature file across Java execution levels.
For EE 10 we have to run against Java 11 and 17, IIUC, so it'd be nice to have one sig file to cover both.

FYI, the CDI/BV TCKs do not seem to need the -IgnoreJDKClass fix for eclipse-ee4j/jakartaee-tck#156 when running on different Java SE versions (For EE 9.1 compatibility testing of WildFly, CDI/BV signature testing just worked on Java SE 11 + 17).

I'm +1 for updating the Maven plugin to support additional options that are compatible with the Platform TCK signature test tooling.



2.  https://github.com/jtulach/netbeans-apitest/pull/7  I think it'd be useful to have more control over the classpath and not have to drag in proj deps and consider transitive scopes, etc.

QUIRKS / OBSERVATIONS

Not complaining here just sharing some observations.  

1.  Signature file v4.1 format changed

In batch we'd been using the unofficial-looking:  net.java.sigtest::sigtestdev:3.0-b12-v20140219 coordinates in the past, to generate a sig file which listed "v4.1" in the header.

Well, the sigtest-maven-plugin also by default uses "v4.1" format.   But using the old sig file in sigtest-maven-plugin blows up because the format slightly changed:

For sigtestdev the "init()" is formatted like:  
   cons public <init>()  
while for sigtest-maven-plugin it's formatted like:   (missing <brackets>)
   cons public init()

Easy to correct for but it proves there's not a clear universal definition of say the v4.1 format.

https://github.com/jtulach/netbeans-apitest is based on an older version of the OpenJDK sigtest tooling which is why the file format is different. 



2.  Downgrading of certain errors into warnings.

In batch we used to document verifyint the SigTest setup by removing the CDI javax.enterprise.util.NonBinding  annotation from the test classpath.     It would result in an error unless you ran SigTest with this class present.  
OTOH, running sigtest-maven-plugin  this exact same step results merely in a warning.

First, just to quickly summarize some of the benefits of signature test tooling:

  • SPEC API super setting is not allowed.


I wasn't using the Maven plugin but I did document some of the testing that I did on https://github.com/eclipse-ee4j/jakartaee-tck/issues/156#issuecomment-816771852 (verified that SPEC API supersetting + subsetting are not allowed).



Is this a big deal?  Well, I'm not sure.. just observing the difference.

3.  Personal account - I'm not complaining... the POM clearly links back to the source repo.    But longer-term for a key project in the Jakarta ecosystem, it would be unusal to have something with the role of this plugin hosted in someone's personal repo perhaps?  
If Jakarta is the one driving usage perhaps we'd have to ask if NetBeans wants to take this forward or else take ownership ourselves?   Maybe I'm getting ahead of ourselves here though..just noting for now.

Thanks for sharing and caring about the signature test tooling!  Short term, it would be great if the different sigtest tools allowed the same checking options.  Longer term, I think Jakarta EE needs signature test tooling that is easier to maintain. 




---

I also couldn't get mvn to handle the ct.sym system scope dep correctly with a Java 8 JDK... but I guess don't care only needing to handle 11, 17 for EE 10.

The -BootCp option might only work correctly on JDK9+, not really sure if that is ignored on Java 8 JDK or if a lib/ct.sym is looked for.


Hope that helps,
------------------------------------------------------
Scott Kurz
WebSphere / Open Liberty Batch and Developer Experience
skurz@xxxxxxxxxx
--------------------------------------------------------


_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev

Back to the top