Please give me a shout when the
TCK is ready for me to look at it again. Once it's ready,
the links for the Spec. committee PR (content and
conversation) and the link pointing to the TCK for the certification CCR issue will
all need to be updated. I'm hopeful a single zipped archive
will be produced that contains all the required material
we've been discussing. If there's still a question about
anticipated content, either reach out directly to me, or
refer to the previous TCK as a guide. It is
my understanding that the project will produce two TCKs --
one with the project license (EPL + CDDL) and one that has
the EFSL -- the two archives only differ in this specific
license file
<archive-file-name>.zip/concurrency-tck/LICENSE.md.
You can copy the license text files from the previously
produced TCKs if you like (Concurrency 2.0.1 EFSL TCK; Concurrency 2.0.1 Project License
TCK). The specification process doesn't specifically
check for the project license TCK so, if that didn't happen
-- it wouldn't delay my starting the ballot.
The Concurrency TCK
job is a work in progress I was wanting to work on that
to package the license file. I’ll do some more on it
over the Easter break.
Steve
With the deadline for specification TCKs
getting closer, I tried submitting a couple of builds to
determine if everything is being packaged correctly so
that we can proceed to run the TCK and report results.
Unfortunately, more help is still needed from those who
know what they are doing with the process and CI. I
copied Steve who was going to try to help get us through
the former and Arjan who has offered to help with the
latter although last I heard was still having trouble
getting access to the CI.
Here are the latest builds that I
submitted,
1. Concurrency API release build (which also
packages the TCK for maven):
https://ci.eclipse.org/cu/job/concurrency-api-release-build/65/
This seems to have done well with the API
jar:
https://jakarta.oss.sonatype.org/content/groups/staging/jakarta/enterprise/concurrent/jakarta.enterprise.concurrent-api/3.0.0/
but the TCK jar appears to be missing the
license file,
https://jakarta.oss.sonatype.org/content/groups/staging/jakarta/enterprise/concurrent/jakarta.enterprise.concurrent-tck/3.0.0/
2. Concurrency TCK master build (I assume this
is what builds the TCK zip for the official run, but I
really don’t know)
https://ci.eclipse.org/cu/job/Concurrency%20TCK%20Master%20Build/24/console
It complains about not being able to find snapshot builds on staging,
jakarta.enterprise.concurrent:jakarta.enterprise.concurrent-tck:jar:3.0.0-SNAPSHOT: Could not find artifact jakarta.enterprise.concurrent:jakarta.enterprise.concurrent-api:jar:3.0.0-SNAPSHOT in sonatype-nexus-staging
but I didn’t even want to build a snapshot.
I was trying to build a candidate for final. I couldn’t
figure out way to submit this with parameters that say
to use 3.0.0 rather than snapshot, so maybe the problem
is that I don’t know how to use it.
Sorry, I
don't know if this is still an issue -- in the Platform
TCK, their build process creates two sets of TCKs -- one
that packages the release ZIP with the project license
(EPL + GPL v2 w/CpE) and another that uses the EFTL
license. They do NOT modify any of the source license
headers, nor anything else that I know of. So, the only
change is to swap out the "top-level" LICENSE.md file.
This could be done as a simple substitution, or as part
of your build pipeline. As a reference example, compare
the top directory in
soap-tck-3.0.0.zip/soap-tck/LICENSE.md vs.
jakarta-soap-tck-3.0.0.zip/soap-tck/LICENSe.md in
1. EFTL SOAP Attachments TCK
2. EPL SOAP Attachments TCK
You should
see that there are no differences between these two
archives except for that license file. (The file names
do differ but that's more a convenience to tell the two
apart than anything else.)
Since
Eclipse Foundation hasn't provided triple license
text/mark-down files, I recommend you just make two
distributions. The EFTL copy will be copied up to the
"official" specification download folder. The project
license TCK can be used by anyone but doesn't contain
the provisions necessary for application of the actual
certification approval.
This should
not have any impact on any product bits although
technically, for certification, you must use the TCK
from the release that includes the EFTL and when you
submit your certification, you will need to reference
the EFTL, final (or proposed final) TCK. So, there may
be additional testing obligations, but the TCKs
shouldn't be included in anything you ship.
As for
producing the TCK -- (if that's what you mean by
"shipping") -- you may make the EPL TCK available
anywhere you like. Some projects use the Eclipse
download server. Some project rename the extension to
.jar and push the zip to Maven central. As for the EPL
copy, our process requires that the proposed file TCK be
pushed to the eclipse download site -- the Spec.
committee mentor (me) will push it up to the official
download folder, once the ballot is completed. The
Platform TCK project just leaves these released TCKs on
their download server.
For the
purposes of certification -- what is important is that
you use tests that come the file that has the same SHA
sum hash. This doesn't change if the file is moved from
one download location to another, nor even if the file
name changes. But the hash will change if any of the
content changes. So -- once you have the proposed file
TCK zip -- make your final certification test run,
capture the results -- With those, you can complete the
CCR issue using the SHA sum hash and that won't change
by virtue of any of the final release processing we do
once the Spec. ballot is completed so ... there won't be
any need to re-run the tests, once the TCK zip is moved
into it's final d/l spot.
Let me know
if you have more questions.
-- Ed
On 3/25/2022 7:53 AM, Scott Marlow wrote:
Hi
Nathan,
I
can attempt to take over the process stuff
although I also do poorly with it, I’m not
familiar with it and don’t understand it. I will
therefore require a lot of support from someone
who does get the process stuff. It’s not obvious
to me from the comments below what are the key
things that need doing to get this over the line
can someone spell out the tasks in simple words
😉.
I’m
not sure how adding a license to the TCK will
require you to release a new Beta of OpenLiberty
although I take your word on that.
Can
one of the mentors answer the question RE:
shipping a jar as part of the TCK. I am
definitely not familiar with shipping a TCK? I
am also not too familiar with the work done to
bring the TCK into this project from the old TCK
project.
I
will take a look at the Javadoc generation.
Thanks
Steve
I need help with some of the
comments that have been raised (mostly around
license issues) in the release review issue
under
https://github.com/jakartaee/specifications/pull/449
“The TCK must be licensed
under the EFTL. For distribution via Maven,
the TCK may be dual licensed: EFTL + EPL.
Please revise the tom-level license docs and
discard the EPL + GPL v2 license docs.
Source-code license headers need not be
updated.”
Could someone who knows what they are doing
with licenses correct the above? Does this
require re-building the candidate final copy
of the TCK? If so, this will push us out a
month (if we can get everything corrected and
rebuilt within a week) and otherwise longer
because our candidate compatible
implementation will need to publish another
beta upon which we can run any updated TCK.
“I will need to get clarification from the
Spec. committee about the final distribution
of the TCK materials. Current check-list
requirement is that we provide the TCK as a
complete bundle .zip file that is linked to
the controlled Specifications download folder.
For CU 3.0, this would be:
download.eclipse.org/jakartaee/concurrency/3.0/jakarta-concurrency-tck-3.0.0.zip
-- You can use the CU
2.0 archive to review the contents if
that is helpful. Also please review the Mentor
Checklist items 6, 7, and 8 for additional
details.”
If I understood the above correctly, it sounds
like splitting the TCK out of platform and
building it in our main project might not fit
with some of the rules, although I know
several other specifications are doing the
same. Our TCK is a JAR file suitable for
publishing to Maven, not a ZIP,
https://jakarta.oss.sonatype.org/content/groups/staging/jakarta/enterprise/concurrent/jakarta.enterprise.concurrent-tck/3.0.0/
Hopefully, Ed will be able to get
clarification allowing us to continue using
this approach, and that would seem to cover
most of the troubles with getting sections 6,
7, and 8 checked off, but I also see a
checkbox asking for a “EFTL license file,
preferably named LICENSE.md” which we don’t
have in our TCK, which goes back to the first
issue mentioned.
“I do see that there is a docs folder in the
Maven source archive. This only includes the
license file. Lacking further documentation, I
would recommend this release use the
previously created cu 2.0 TCK zip as the
proposed list of contents -- if anything is to
be discarded, we can explicitly decide to
remove it.”
I don’t understand the above.
Hopefully, someone else does.
“The Java doc link to the Spec. License HTML
file yields 404 in the Netlify preview. Please
correct if needed.”
I tracked down the above to
https://deploy-preview-449--jakartaee-specifications.netlify.app/specifications/concurrency/3.0/apidocs/
which has some fine print at the bottom of the
page with a copyright “license terms” broken
link to
https://deploy-preview-449--jakartaee-specifications.netlify.app/specifications/concurrency/3.0/apidocs/doc-files/speclicense.html
Sure enough, our generated 3.0
javadoc jar file,
https://jakarta.oss.sonatype.org/content/groups/staging/jakarta/enterprise/concurrent/jakarta.enterprise.concurrent-api/3.0.0/jakarta.enterprise.concurrent-api-3.0.0-javadoc.jar
doesn’t have any
doc-files/speclicense.html
unlike the 2.0 javadoc jar file,
which does have it,
https://repo1.maven.org/maven2/jakarta/enterprise/concurrent/jakarta.enterprise.concurrent-api/2.0.0/jakarta.enterprise.concurrent-api-2.0.0-javadoc.jar
What changed here that got rid of
this and how to correct it? I assume this
will require re-building everything (once a
fix is made) rather than just grabbing the
copy from the 2.0 jar and checking that in.
Would someone else be willing to
take over at this point sorting out the
process stuff? This is an area that I do
poorly with and I’m not even the lead for this
spec.
Hi
Nathan,
As
you are a committer I think you can do those
things which is why you get can get so far. I
don’t remember a lot of the process. I see you
have added Ed/Dmitry I think they are our
mentors available to us to help guide us through
this part of the process.
Steve
Given that we’re supplying the
candidate for compatible implementation and
have the information for it and the results
and so forth, I’ve been trying to fill out
some of the process for the 3.0 release based
on this, and I’ve been surprised how far it
seems to be letting me go without any
additional authorization. Thus far I have the
following two issues mostly filled out (some
links within the checklists won’t be working
until a week from now) and it even allowed me
to update the release record to replace the
projected release date of last October with
Feb 28 and to request a Generated IP Log,
although I have no idea if I’ve done those
things properly or if I should have included
more information. To any of you who know what
you are doing with this sort of process,
please review and correct or fill in parts
that I have missed. I’m hoping that we will
be able to check off the remaining boxes and
submit the release review a week from now. If
anyone else would like to take over, I’d be
happy to let them.
Concurrency 3.0 release review
issue:
https://github.com/jakartaee/specifications/pull/449
Concurrency 3.0 compatibility
certification request issue:
https://github.com/eclipse-ee4j/jakartaee-platform/issues/464
_______________________________________________
cu-dev mailing list
cu-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cu-dev
_______________________________________________
cu-dev mailing list
cu-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cu-dev
_______________________________________________
cu-dev mailing list
cu-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/cu-dev__;!!ACWV5N9M2RV99hQ!fTBjQOsqc5qafs1zMjLGtBiyj3IJewpRKAoFnJOm-qaoJ5aOTeEudL8KuHOroZE$