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://www.eclipse.org/mailman/listinfo/cu-dev