Skip to main content
[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? 
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.

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

Back to the top