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
