[
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?
|
With the SPEC APIs completing soon, I would like to request a new
`sigtest` release with Scott Kurz's (now merged) pull
request that addresses (SPEC API) subpackage validation. I
will request the release now, so that the updated sigtest library
may be added to TCKs for EE 10.
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