[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jakarta.ee-spec.committee] [External] : Re: TCK archive format? (Consider allowing JAR or ZIP)
|
Maybe the problem is with how we are "packaging" the TCK content.
The TCK is the only Spec. artifact we create a SHA Sum for. The
archive we use for the TCK includes the documentation which is
generally not part of a typical Java binary JAR (i.e. at Maven
Central, there's typically a Binary JAR, a Source JAR, a Java Doc
JAR and maybe others -- but they're all separate).
We currently bundle all the TCK component elements into a single
archive -- a ZIP archive. We treat that as a single deliverable.
At the Spec. generation end, that makes production of that archive
a multi-step process. Contrast that with the publication of the
API, binary, and Java Doc JARs with the code-based resources can
directly be published to, Maven central (or another repository
service if the vendor liked). So, the normative code-based Spec.
artifacts can be easily pulled into an Mvn script but the
normative TCK elements cannot.
I'd like the TCKs to be accessible via maven because I think that
improves the access flow for developer users. I understand that
developers typically will need additional details to understand
how to use these artifacts but, once they have that worked out --
I'd like to improve how these can be distributed more readily,
using common build tools (I typically think mvn, but others also
exist). I don't think using the TCK artifacts are all that much
different from using a binary API jar file -- you have to know how
to use the JAR before you pull it in.
In the context of the process we have today -- a binary
(run-time) TCK JAR cannot be pushed to Maven central as a
normative artifact because we track the zip bundle with the SHA
SUM and Signature hash. To "properly" certify an implementation,
even if we pushed the binary elements of the TCK to Maven, users
would still need to pull down the normative copy, unpack and
"install" those artifacts, then run/validate their implementation
with that binary. (Or, just attest that is what they did. I'd
assert that we don't want a process that promotes 'looking the
other way.')
So, I thought, if perhaps we could just create a JAR file that
had the same content as what is currently in the ZIP -- thinking
that maybe we might simplify that process by one step -- but I'm
now seeing that probably isn't going to 'just work.' So just
changing the extension name from .zip to .jar won't cut it.
I want to make it possible for developers to pull normative TCK
binaries down from Maven (or whatever their chosen repository
happens to be). I want the artifacts that are pushed to the
Jakarta EE Spec. download to exactly match what can be accessed
from Maven -- or at least the run-time parts that are actually
used at build-time.
Today, before the Spec. is finally approved, I can pre-test my
implementation using the pre-final TCK .zip files. Once the Spec.
is finalized, that zip is exactly copied to the Jakarta EE
Specification Download folder and the SHA-SUM and Signature hash
are generated (the SHA sum won't change because the binary is
identical and the signature hash works correctly too). So, I
don't need to re-run the TCK because it's unchanged (in any
scenario where a change might have been needed, the SHA Sum would
not be the same and I would need to re-verify the compatibility of
my implementation -- even if the change was to a non-binary
element of that archive.)
I was hoping we could figure this out for EE 10, but maybe it's
just too late to consider making changes to allow for this that
rapidly.
Does this make sense?
-- Ed
On 12/8/2021 11:36 AM, Scott Stark
wrote:
There is no access to a user guide (required) and
any example CI setup that is often included in a full TCK dist.
Users certainly should have the ability to directly access the
components directly via a repo, but I don't see how that can be
the only mechanism when it comes to ratifying the associated
spec. Am I missing the context in which you are asking about
this?
Thanks Scott.
This seems to suggest that users should NOT have
access directly to the normative TCK artifacts -- That
they should pull the comprehensive archive, unpack and
digest it, THEN, utilize the contents. Is that a fair
re-state?
We include GAVs for the API jars and JavaDocs. Why
would we want to enforce force additional overhead on
the TCKs (both on construction of the archive and on
consumption)? (Or, what it is about TCK usage that I'm
minimizing.)
-- Ed
On 12/8/2021 8:02 AM, Scott
Stark wrote:
For the final submission I still think
there needs to be a single zip that is
comprehensive. The use of jar artifacts in a repo
facilitates the ability to easily integrate TCK
testing into CI environments, but it is a bad
starting point to running the TCKs. Only after you
have gone through the full zip distribution and
associated user guide/example do you start wanting
the individual artifacts.
Hi,
As we move the TCK responsibilities to
component projects and, as we
continue migrating away from the legacy TCK
build tools, to MVN or other
build tooling, I wonder if we should hold on
to the requirement that we
only accept .zip file bundles for normative
TCK submissions.
Would the committee be interested in
relaxing the formal requirements to
allow either <name>.zip OR
<name>.jar? If we did this, projects
would
not need to create multiple bundles and we
could start to use Maven
Central or other types of distribution
mechanisms more directly.
I believe all other requirements (SHA Sums,
contents, etc.) can be
maintained just as directly with either file
format.
Comments?
I don't know that we could adopt this before
the close of the year, but
... perhaps this is simple enough to take up
without extensive discussion.
Thanks,
-- Ed
_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee__;!!ACWV5N9M2RV99hQ!a7DQDPqHeJq3Q0JbFqLFGnY9MKejqQtnohN_jFIYScnrOBo80YCr4N58Bxi9VNM$