Here’s
me thinking a jar file is a zip file with just a different
filename suffix
😊
I’ll
review the mvc-spec and see if we can do it.
Steve
Discussion of the TCK process came up on
today’s Jakarta EE Platform call, and it was clarified that
a single ZIP file artifact is needed and that it cannot be a
JAR file. It sounds they will be considering making the TCK
process more flexible for future Jakarta EE releases, but
that doesn’t help us for now.
One useful piece of information was passed on
to me by Ivar Grimstad just as the meeting was starting, who
says it is possible to have the TCK be both a jar file on
Maven and also be built into a single zip artifact, and that
he has done so with the MVC spec, which we could copy from,
https://github.com/eclipse-ee4j/mvc-tck
Steve, do you think it would be possible for us
to do the same for Concurrency?
Steve,
Thanks so much for helping out with the process
aspects.
Yesterday I tried to cover as much as I could
figure out myself (Thanks for merging the TCK User’s Guide
updates!) Here is my best understanding of everything that
remains to be done,
·
jakarta.enterprise.concurrent-api-3.0.0-javadoc.jar
needs to have doc-files/speclicense.html within it as the
2.0 javadoc jar did
·
The
TCK binary,
jakarta.enterprise.concurrent-tck-3.0.0.jar
needs to include:
o
The
TCK User's Guide,
https://github.com/eclipse-ee4j/concurrency-api/blob/master/tck/README.md
o
LICENSE.md
with an EFTL license, optionally also EPL license
o
The
TCK jar file might need to be renamed to be a zip
file. I don't like this at all for publishing it Maven where
projects will want to consume it as a jar file as it
currently is. We need clarification on whether the rename
to zip is truly a requirement. The checklists that were
added to
https://github.com/jakartaee/specifications/pull/449
do refer to it as a zip file, however, there is also
language like this, "Link to final TCK download zip file of
the form
https://download.eclipse.org/jakartaee/{spec}/x.y/*{spec}-tck-x.y.z.zip
(The folder path is required, the file name pattern is
preferred.)" suggesting that this part of the name might be
optional, and only the folder path is a requirement.
Ed will need to clarify.
·
Our
top-level LICENSE.md for the whole project
https://github.com/eclipse-ee4j/concurrency-api/blob/master/LICENSE.md
is currently EPL + GPL v2 with CLASSPATH exception.
Ed might have been saying to also switch this to EFTL + EPL.
I'm not sure if that was intended, or if the comment only
meant top level for the TCK?
Ed, please confirm if doing the above would
satisfy the remaining issues with the spec review?
Regarding the need to release a new Beta of the
candidate compatible implementation, I was thinking that
because a new build of the Concurrency TCK will be needed to
make these changes and will also result in a new build of
the API JAR, that we would need to include the new API JAR
in a new Beta. However, if it ends up being identical from
an API standpoint to what is already in the Beta because no
impactful changes have gone in, then I suppose we wouldn't
actually need a new Beta and could run the new TCK that gets
produced to fulfill the process requirements against the
existing Beta release.
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