| Re: [jakartaee-tck-dev] Plan to publish archives of TCK refactor modules to maven |
On 2/12/24 14:10, Alwin Joseph via jakartaee-tck-dev wrote:
Hi Team,
As we have staged the new refactored versions of few standalone TCKs at [1], it has become a requirement to publish at least the common modules in tckrefactor [2] to maven repository.
Some of the common modules which would be used by other TCKs for execution are common, runtime, signaturetest and libutil among others.
Based on the past discussions it was agreed to use “jakarta.tck” as the groupID for the modules in platform TCK. The sigtest tool was released to maven at [3] using this groupid via [4] by Scott Stark.
- One of the primary questions that arises in this scenario is whether these common modules from the platform TCK need to be licenced with EFTL or EPL. Also do we have any other options for naming than “jakarta.tck”?
- Generally, we would also want to release TCK archives to maven which will be convenient for certification. Earlier we had published the Jakart REST TCK(3.1.4 for EE10) with EFTL to maven central at [5] after discussing the same in [6]. We would like to continue publishing EFTL TCK jars or archives to maven for other specifications as well.
1. The discussion thread about groupId seems to have settled down with only positive responses to use "jakarta.tck". Regarding license use, as long as we release clearly identified TCKs that cannot be used for certification, I favor the EFTL license for the reason of simplifying the development process of what the TCK team builds. By "clearly identified TCKs", I mean early TCK builds, each with a consistent groupId:Artifact:VersionId where the VersionId reflects that the TCK is not yet ready for certification use.
2. In the past we have staged TCKs on the eclipse.org downloads page similar to [1]. Staged TCKs aren't sufficient for certification requests but they are sufficient for the Spec Ballot process as long as it is known that staged TCK snapshot contents have not changed (if TCK contents do change, the Spec implementation has to be retested). I think that if we build "clearly identified TCKs" during the ballot process that we should be to push TCK archives to Maven repositories.
The [6] feedback is good to see, do we need to check with the Specification Committee on pushing TCK archives to Maven?
Scott
Please share your thoughts.
[1] https://download.eclipse.org/ee4j/jakartaee-tck/jakartaee11/staged/eftl/
[2] https://github.com/jakartaee/platform-tck/tree/tckrefactor/
[3] https://mvnrepository.com/artifact/jakarta.tck
[4] https://ci.eclipse.org/jakartaee-tck/job/SigtestPluginRelease/
[5] https://mvnrepository.com/artifact/jakarta.ws.rs/jakarta-restful-ws-tck/3.1.4
_______________________________________________ jakartaee-tck-dev mailing list jakartaee-tck-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev