Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-tck-dev] [External] : Re: Seeking clarification to question about Milestone TCK releases



On Wed, Mar 20, 2024 at 8:53 PM Ed Bratt <ed.bratt@xxxxxxxxxx> wrote:

Scott,

We were unable to reach any conclusions in the Specification committee meeting today. It turns out there is a rather complex list of license documents and processes that need to be examined to make sure that we don't inadvertently impact one or the other.

Thanks Ed for initiating the discussion!
 

I believe the conversation consensus was, essentially -- keep doing what we have been doing in previous releases and, common library components are not "special" and should just be published under the project license.

+1

More details:

For binary artifacts in a common library, so long as there are no specification assertions that are somehow contained within these components, these artifacts should be published under the project license (for Jakarta EE TCK project, I think that is dual-license, EPL and GPL v2+CPE but you are welcome to confirm that). There is nothing in the process that I am aware of, that prevents publishing (and subsequently retrieving) these to a Maven repository.

We created https://github.com/jakartaee/platform-tck/issues/1263 for checking if any other licenses should be added.  The output from the scancode tool that can be used to aid updating the project license list is attached to the issue (in the form of a html file in a zip).

We also created https://github.com/jakartaee/platform-tck/pull/1262 to remove the Platform TCK copy of the EFTL license to ensure that we don't use that but will instead use the project license.

For the TCKs, the Spec. committee would recommend following the existing process -- all publications of the TCKs (continuous build, milestone, pre-final, even final) should be made using the project license.

+1

The TCK license should only be applied to the proposed final release. The Spec. Committee will track the SHA-SUM of the proposed final TCK. Finally, the Spec. committee will compute a SIG-SUM, only after the specification is accepted final. The project license TCKs may be published to any location that is within the project charter and it is my belief that the complete TCK may be published to a Sonatype Maven repository. 

+1
 

The Spec. committee was unable to reach any conclusion regarding publication of Final specification TCKs to a public Maven repository, though there was speculation that there are specifications that may do this already. I am not aware of any requirement, nor even any desirability for publishing any TCK that is not proposed final with a TCK license. Furthermore, the hash tracking that the specification process provides has no facility for ensuring that the archive has been obtained from one location or another so if a final TCK were obtained from maven central, that TCK would pass via all the HASH checks (There may be a process requirement about download location and that is one of the things that needs further research by the Spec. committee). Additionally, any pre-final TCK release that is promoted to final (i.e. CI build, Milestone build, whatever, promoted without rebuilding) will pass the HASH sum checks. Unfortunately, the process we are under (at least as outlined here) recommend that only a Proposed Final TCK include the EFTL and this will almost certainly require the archive be rebuilt on anything published earlier than a proposed final release.

I realize this may force rerunning tests that have been performed on pre-final releases but, until we are able to work out additional details of the process and license, we cannot make other recommendations.

CI, Milestone Release TCK -- any TCK build that is published for early access and testing

+1
 

Proposed Final TCK -- TCK that is built with the intent that this TCK will become a final release. SHA SUMs are used to track these TCKs in CCRs that are created for the purposes of the release ballot. Once a ballot has started, a proposed final TCK may not be altered in any way without invalidating the the current ballot for that specification. We do not do this but we could designate Accepted CCRs using TCKs with this SHA SUM as provisional until the Specification is promoted to final status. So far, this has not seemed necessary.

Final TCK -- A TCK that has been successfully ratified and is part of a Final Specification. SHA SUM is tracked and a when the ballot is successful, a SIG SUM is computed for this TCK archive. CCRs with matching SHA SUMs are now final complete (if we used the provisional tag, we could remove that, but this is not currently part of the process) -- We generally do not use the SIG SUM but it is available as an additional check, if there ever was any question about a specific TCK. It is my understanding that Final TCK archives must be made available under both the project license (since that is the license the work was performed under) AND the TCK license.

If you could, please reply with some specific problem cases that you are encountering so that we can be sure that the Spec. committee properly addresses the problems you are experiencing.

There have been two problems in past EE releases:

1.  Specification teams not having a consistent way to know if the current staged TCK is the same one that they already tested against.  We applied a creative solution to maintain a history of the past N staged TCKs but still, the problem was not completely solved (e.g. we just published a new 4.0.1 JAX-WS TCK that I thought was already solved in the JAX-WS 4.0.0 TCK (issue link) which is a sign that our current way of staging TCKs needs improvement).  Any TCKs that we publish to a Maven repository should have a consistent name and not be a Maven snapshot release to ensure consistency in the testing experience.

2.  The other general problem with consistency in the (Specification) testing experience is that not all pre-final specification api releases are pushed to a public Maven repository.  This is a problem that impacts EE spec implementations that want to participate (pre-final) in the EE 11 development process but cannot since some pre-final specification api releases are only pushed to the Jakarta staging repo which leaves community projects out of the game.  In a small way, the Platform TCK team pushing pre-final TCK releases to a public Maven repository should help some of the community projects but time will tell if that really helps with ensuring consistent access to pre-final TCKs.

Thanks Ed!
 

Thank you.

-- Ed



On 3/20/2024 8:36 AM, Ed Bratt via jakartaee-tck-dev wrote:

OK. I will raise the question about publishing pre-final TCKs AS WELL AS the question about common binary artifacts.

-- Ed

On 3/20/2024 8:09 AM, Scott Marlow wrote:


On Wed, Mar 20, 2024 at 10:57 AM Ed Bratt <ed.bratt@xxxxxxxxxx> wrote:
Hi Scott

In the EE Platform meeting yesterday I had thought that the question
being asked was: what license should be applied to pre-final (e.g.
Milestone) releases of TCKs. It has been suggested that there is a
question about how to publish common binary artifacts that each
component TCK test system may need to consume to perform the tests.

It is true that we also want to publish common binary (Platform TCK) artifacts that may be used by each Component TCK system for which we intend to release milestone releases for if allowed to do so. 
 

Could you please clarify -- are you asking about the requirements for
publication of a pre-final TCK, or are you asking about requirements
implied for a set common utility artifacts?

I did mean to ask about publication of a pre-final TCK but good point to ask about requirements for a set of community utility artifacts.  
 

If you could describe the problem or potential problem you have, today,
that would also be helpful.

Today or soon, I planned to complete a milestone release of common (Platform TCK) artifacts that may be used by Component TCK system found in the Platform TCK. 

 

I ask because, I believe that the TCK license just applies to tests. Not
to the machinery used to run those tests. My initial reaction would be
-- common binary artifacts should be licensed under the TCKs 'project
license' only.
+100


If you can, please try to clarify within the next hour since the Spec.
committee begins a 9 AM pacific daylight time (65 minutes from now).

Thanks Ed!
 

Thanks,

-- Ed


_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev__;!!ACWV5N9M2RV99hQ!ILLbIa8F1tlMLswTNNB5hxBB-pg_ZMNBDjSNzdDXaILO2dabm4KRq-dZGlgjxoGldKKdlEiRgWVAa4hktqsAtv8354M$ 

Back to the top