| Re: [jakarta.ee-spec.committee] [External] : Re: TCK archive format? (Consider allowing JAR or ZIP) |
Or, maybe we could consider possible refactoring of the material. For example, we don't push the written Spec. documents to Maven, but we do push all the API JARs. Maybe some similar 'factoring' of the TCK material would be appropriate. We could, for example, track the SHA Sum and Signature Hash of just the runnable elements (the artifacts that are actually used to validate compatibility).
I'm bummed it is more complex than just an extension name change. Sigh.
-- Ed
I see what you are driving at, but this will definitely take some thinking about how to achieve. One could probably publish all of the relevant artifacts to a maven repo using qualifiers/naming conventions to cover user guide, exception list, etc.
On Dec 8, 2021 at 4:58:57 PM, Ed Bratt <ed.bratt@xxxxxxxxxx> wrote:
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?
On Dec 8, 2021 at 12:09:53 PM, Ed Bratt <ed.bratt@xxxxxxxxxx> wrote:
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.
On Dec 8, 2021 at 9:58:16 AM, Ed Bratt <ed.bratt@xxxxxxxxxx> wrote:
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$