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$