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
·
EFTL SOAP Attachments TCK
·
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