[
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