|
On 2018-10-08 3:28 PM, Bill Shannon
wrote:
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.
I think Kevin does have a point. The current draft TCK agreement
says that only "...use in binary form without modification
is permitted...". At a minimum the license will have to allow for
those modifications expressly required by the TCK itself. Which is
easily done now that we understand that it is a requirement. Thanks.
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.
![Avast logo]()
|
This email has been checked for viruses by Avast antivirus software.
www.avast.com
|
|
