| [jakartaee-tck-dev] Some observations / action items using sigtest-maven-plugin in Batch standlone TCK |
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
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.
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.
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.
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.
---
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.
Hope that helps,
------------------------------------------------------
Scott Kurz
WebSphere / Open Liberty Batch and Developer Experience
skurz@xxxxxxxxxx
--------------------------------------------------------