| Re: [jakarta.ee-spec.committee] [External] : Re: TCK archive format? (Consider allowing JAR or ZIP) |
Mike,
I believe we have previously discussed and received assurance that dual-licensed TCKs (any artifact) are acceptable to Sonatype. So, these would require both the TCK license and the project license. Currently, the TCKs are produced under the project license while they are under development. When they are finalized, they are made available under the TCK license. I thought that we determined dual license was acceptable from the Working Group / Eclipse side but, if you are not sure, please do check if this is still allowable.
The certification process steps still require the Compatibility Certification Request with it's attestations. The Branding and Trademark processes is also still a requirement for those who choose those paths.
Subject to your assurance that this is an allowable delivery pattern, my goal with this discussion is to see if there is an opportunity for us to make the TCKs operate like any other Java element and can be built into the same developer delivery channel as other Java artifacts. I view this as a simplification and broadening of availability effort.
Emily and others, when a CCR is submitted, the submitter is required to include the SHA-256 hash of the TCK package that they used for their certification. Only finalized and approved TCKs and their corresponding SHA sums are acceptable. Therefore, only a single distribution is allowed -- under our current process.
Part of this discussion is to work out how to adjust our process,
if we can find a proper solution that meets all procedural and
mechanical requirements.
-- Ed
Beyond any technical considerations the licensing and patent IP flows in the JESP/EFSP are predicated on the use of the normative TCK binary made available under the TCK License. So there would be legal analysis required to enable this scenario.
On 2021-12-08 7:13 p.m., Scott Stark wrote:
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$
_______________________________________________ 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--
Mike Milinkovich
Executive Director | Eclipse Foundation AISBL
Twitter:@mmilinkov
_______________________________________________ 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!fHraA8um0eKgNng_5TBlhok7ptQ-hZo0sO2H1FIv2Xg8a05iTGZzOJcdydYSpfc$