Yes, I think you're over-rotating on "binary only". You have to
follow the rules of the TCK. The rules may allow or require
reassembling jar files or adding implementation-specific porting
code before running the tests. But in general the tests will be
supplied as binary class files that have to be used as is. You
don't start from the TCK source repository and build from there.
Kevin Sutter wrote on 10/08/2018 09:09
AM:
Hi,
We've been talking recently about
a
binary-only distribution of the TCK for licensing purposes. I
don't
think this will be sufficient in all cases. I know that we
(IBM)
have had to re-build some of the buckets in the past, so I
double-checked
with our CTS lead. Here's what he provided...
The CTS Users Guide states in
section
5.3.4 & 5.10 that the following buckets are rebuildable (if
necessary).
Section 7.7 calls for possible
rebuilding
parts of the ejb30 bucket.
There are also some tests in JMS
which
may require rebuilding in certain situations (our latest efforts
with WebSphere
Liberty have not required this step).
And, our own Java Batch required
rebuilding
if CDI is not used for injection (WebSphere uses CDI, so
this one
didn't apply to us).
Point being is that there are already documented exceptions to
the binary-only
approach. Of course, the use of the standard binaries would be
the
preferred approach. But, we have to be aware of the exception
cases
that may arise or already exist so that we're not boxed into a
corner.
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Java EE architect
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
|
