| Re: [cu-dev] [External] : RE: Release process for Concurrency 3.0 spec |
_______________________________________________The important thing is that we have a single archive that contains all the elements of the bullet list (below). We use the SHA-256 Sum to determine that the contents are one and the same so, if it's called .jar or .zip it doesn't matter (so far as I can determine). So, if you post the file with the exact same contents as .jar to Maven central and as .zip to download.eclipse.org -- I think all will be peachy.
In the final release the process a specification project must deliver both a TCK with the project license and a TCK with the EFTL. In practice -- there must be /either/ two archives made available -- one with the project license (in this case, EPL + GPL v2 w/CpE) and the other with EFTL -- /OR/ a single archive that contains the project license AND the EFTL. In the past, two .zip archives were published (one with EPL + GPL and the other with EFTL). The EPL + GPL (alone) copy is not suitable for a certification request since certification requests require the user abide by the EFTL. Community users are welcome to use the TCK under the project license as they like (under those license terms), just not for certification. The (in this case) triple-license version would eliminate the need for multiple archive copies (.zip or .jar).
I'd be cautious about using MVC Spec since it's not yet been part of a Platform cycle -- that said, it should be following all the rules.
The Spec. committee is, I believe, committed to addressing the complexity described above -- it's just not clear it can get that done in time for the release deadlines for EE 10.
So far as I am aware, if you follow the content of the previous release concurrency TCK, you will deliver what is required.
If it my understanding that these two zip files only differ in the top-level License.md file <File>/concurrency-tck/LICENSE.md. The only one that has a valid SHA-SUM and a valid signature key is the EFTL copy.
-- Ed
On 2/15/2022 10:04 AM, Steve Millidge (Payara) wrote:
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
From: Nathan Rauh <nathan.rauh@xxxxxxxxxx>
Sent: 15 February 2022 17:01
To: Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx>; cu developer discussions <cu-dev@xxxxxxxxxxx>
Cc: Dmitry Kornilov <dmitry.kornilov@xxxxxxxxxx>; Ed Bratt <ed.bratt@xxxxxxxxxx>
Subject: RE: Release process for Concurrency 3.0 spec
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?
From: Nathan Rauh <nathan.rauh@xxxxxxxxxx>
Date: Tuesday, February 15, 2022 at 8:53 AM
To: "Steve Millidge (Payara)" <steve.millidge@xxxxxxxxxxx>, cu developer discussions <cu-dev@xxxxxxxxxxx>
Cc: Dmitry Kornilov <dmitry.kornilov@xxxxxxxxxx>, Ed Bratt <ed.bratt@xxxxxxxxxx>
Subject: Re: [EXTERNAL] RE: Release process for Concurrency 3.0 spec
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.mdo 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.
From: "Steve Millidge (Payara)" <steve.millidge@xxxxxxxxxxx>
Date: Tuesday, February 15, 2022 at 3:56 AM
To: Nathan Rauh <nathan.rauh@xxxxxxxxxx>, "Steve Millidge (Payara)" <steve.millidge@xxxxxxxxxxx>, cu developer discussions <cu-dev@xxxxxxxxxxx>
Cc: Dmitry Kornilov <dmitry.kornilov@xxxxxxxxxx>, Ed Bratt <ed.bratt@xxxxxxxxxx>
Subject: [EXTERNAL] RE: Release process for Concurrency 3.0 spec
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
From: Nathan Rauh <nathan.rauh@xxxxxxxxxx>
Sent: 14 February 2022 17:11
To: Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx>; cu developer discussions <cu-dev@xxxxxxxxxxx>
Cc: Dmitry Kornilov <dmitry.kornilov@xxxxxxxxxx>; Ed Bratt <ed.bratt@xxxxxxxxxx>
Subject: RE: Release process for Concurrency 3.0 spec
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.jardoesn’t have any doc-files/speclicense.html
unlike the 2.0 javadoc jar file, which does have it,
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.
From: "Steve Millidge (Payara)" <steve.millidge@xxxxxxxxxxx>
Date: Wednesday, February 9, 2022 at 9:12 AM
To: Nathan Rauh <nathan.rauh@xxxxxxxxxx>, cu developer discussions <cu-dev@xxxxxxxxxxx>
Cc: "Steve Millidge (Payara)" <steve.millidge@xxxxxxxxxxx>, Dmitry Kornilov <dmitry.kornilov@xxxxxxxxxx>, Ed Bratt <ed.bratt@xxxxxxxxxx>
Subject: [EXTERNAL] RE: Release process for Concurrency 3.0 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
From: Nathan Rauh <nathan.rauh@xxxxxxxxxx>
Sent: 08 February 2022 17:44
To: cu developer discussions <cu-dev@xxxxxxxxxxx>
Cc: Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx>; Dmitry Kornilov <dmitry.kornilov@xxxxxxxxxx>; Ed Bratt <ed.bratt@xxxxxxxxxx>
Subject: Release process for Concurrency 3.0 spec
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
Ivar Grimstad
Jakarta EE Developer Advocate | Eclipse Foundation Eclipse Foundation - Community. Code. Collaboration.