[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jakartaee-tck-dev] Issue with sigtest-maven-plugin - no easy way to validate no new "subpackages" added?
|
On 1/31/22 5:03 PM, Scott Marlow wrote:
As a test, I removed `CLSS public abstract interface jakarta.batch.api.Decider` from my local EE 9.1 TCK jakarta.batch.sig_2.0_se8 file and ran the signature tests to see if the presence of
jakarta.batch.api.Decider is detected in the implementation, I didn't see a signature test failure for that. I'll repeat the experiment with Jakarta EE 8.
I removed the `CLSS public abstract interface
javax.batch.api.Decider` from my local EE 8 TCK
javax.batch.sig_1.0_se8 file and ran the signature tests and do
see a failure:
Added Classes
-------------
javax.batch.api.Decider
Scott
FYI, the requirements are called out in the Platform TCK user guide, some of which I will paste here for the discussion:
"
EE-WP7 The Product must contain the full set of public and
protected
classes and interfaces for all the Libraries. Those classes and
interfaces must contain exactly the set of public and protected methods,
constructors, and fields defined by the Specifications for those
Libraries. No subsetting, supersetting, or modifications of the public
and protected API of the Libraries are allowed except only as
specifically exempted by these Rules.
EE-WP7.1 If a Product includes Technologies in addition to the
Technology Under Test, then it must contain the full set of combined
public and protected classes and interfaces. The API of the Product must
contain the union of the included Technologies. No further modifications
to the APIs of the included Technologies are allowed.
"
Scott
On 1/31/22 3:39 PM, Scott Kurz wrote:
I found an issue
experimenting with the sigtest-maven-plugin (org.netbeans.tools:sigtest-maven-plugin:1.5) we're using in the Batch, and
other TCKs.
While this seems like it'd be
a very minor issue if found earlier, this late in the cycle
I'm not sure we'll get an ideal solution.
The problem is it doesn't
seem to currently provide a way to ensure that no new
packages have been added.
E.g Jakarta Batch API
includes packages:
jakarta.batch.api
jakarta.batch.api.chunk
jakarta.batch.api.listener
BUT I don't see a way to
prevent an impl from providing, say, a bogus jakarta.batch.api.dummy package.
It's possible I'm missing how
this is supposed to work. However, I think it's just a
simple bug.
I put in a PR: https://github.com/jtulach/netbeans-apitest/pull/10/files but note sure when to expect a
response. As you can see in the PR, it seems the -Package option needs to be used, rather
than the -PackageWithoutSubpackages
option.
I'm not sure I could find a
place in the process where this is required... but I vaguely
recall in the Java EE timeframe thinking this type of
validation was required.
Besides the standalone Batch
TCK, I see the CDI TCK using this approach, it looks like: https://github.com/eclipse-ee4j/cdi-tck/blob/58bdab7b2d4b31fa28356f3530f3af56d1f87019/impl/src/main/resources/sigtest-pom.xml
---
Thinking ahead, our options
might be:
1. Work with owner to get a
release in time (do we have any other issues?)
2. Ship our own plugin fork
(either in an individual TCK or somewhere else)
3. rework Maven to exec the
underlying executable rather than going through the plugin
4. Agree at the platform
level we can tolerate this gap in validation.
Thoughts,
------------------------------------------------------
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