MicroProfile Config 3.0 Specification Review

[Emily-Jiang]

Specification issue template

When creating a specification project release review, create an issue in the MicroProfile-WG repository repo with the content defined as follows.

• Specification name and version
• Add the label Release Review
• Naming conventions for artifacts:
  • Specification PDF in the form of microprofile-project-spec-version.pdf
  • Specification HTML in the form of microprofile-project-spec-version.html
  • project is the microprofile specification short project name (config, health, ...)
  • version is the two digit x.y version of the specification

• The Nexus Staging links (orgeclipsemicroprofile-NNNN where NNNN is the staging repository id) (eg, https://oss.sonatype.org/content/repositories/orgeclipsemicroprofile-NNNN/org/eclipse/microprofile/config/) which contain all the binaries and relevant documentation:
  • Staging Repo
  • Spec PDF
  • Spec HTML
  • Javadoc
  • API Jar
  • TCK Jar

• A link in the Eclipse downloads sections is still available for specs and apidocs:
  • https://download.eclipse.org/microprofile/staging/microprofile-config-3.0/
  • An apidocs directory containing the javadoc associated with the API jar.

• Summary that a Compatible Implementation is complete, passes the TCK, and that the TCK includes sufficient coverage of the specification.
  • [Compatible Certification Request] (Open Liberty 21.0.0.12-beta: MicroProfile Config 3.0 Compatible Certification Request eclipse/microprofile-config#725)

• Release Review
  • Follow governance process and create/update release record
    • Component Release Record
  • Email to PMC (more info here)
  • Start release review by emailing EMO (more info here)(Track the bug issue created by EMO after the email)
  • A member of Steering Committee initiates the ballot by sending an email to [microprofile-wg] (mailto:microprofile-wg@eclipse.org) (more info here
  • After the voting has ended, email [microprofile-wg] (mailto:microprofile-wg@eclipse.org) with the ballot result (more info here

[radcortez]

I reviewed the release output and everything seems to be ok except for:

https://github.com/eclipse/microprofile-config/blob/71c1e87d1fc9468c221672fe5dff33f6f19e32b6/spec/src/main/asciidoc/license-efsl.adoc#L14

The copyright year for the specification is 2020, and the javadoc is 2021. Don't we need to update the copyright spec year to 2021 too so the spec and javadoc are consistent?

[Emily-Jiang]

Thank you @radcortez for spotting the above issue. I emailed Wayne in Eclipse Foundation regarding whether I need to redo the release or doing a service release shortly after MP Config 3.0. Wayne said it is ok to be fixed in the service release.

It's really about degrees of goodness. It is far better for the date to be correct than incorrect.

That it is wrong for a short period of time is not a showstopper. Fixing it quickly with a service release feels like the right approach.

Wayne

Wayne Beaton

Director of Open Source Projects | Eclipse Foundation

[radcortez]

Ok.

[kwsutter]

Looks good, @Emily-Jiang! Just a couple of minor nits on the CCR. Thanks!

Looked closer at the jar files... The javadoc jar file contains the Apache license and the EFSL license, which are okay. But, it also contains the EF TCK license? That should not be part of the javadoc jar file. I don't think this update is a requirement for a respin, but the TCK license should be removed. Open an issue/pr to clean this up after the release.

On a similar vein, the TCK Javadoc jar file contains the EFSL, which doesn't seem right. I think this EFSL should be removed from the TCK Javadoc jar file. Just include this with the issue/pr you create for the previous comment.

[radcortez]

Looks good, @Emily-Jiang! Just a couple of minor nits on the CCR. Thanks!

Looked closer at the jar files... The javadoc jar file contains the Apache license and the EFSL license, which are okay. But, it also contains the EF TCK license? That should not be part of the javadoc jar file. I don't think this update is a requirement for a respin, but the TCK license should be removed. Open an issue/pr to clean this up after the release.

On a similar vein, the TCK Javadoc jar file contains the EFSL, which doesn't seem right. I think this EFSL should be removed from the TCK Javadoc jar file. Just include this with the issue/pr you create for the previous comment.

This was done on purpose to simplify unpacking the resources. Basically, we have a single JAR with all the resources that are unpacked to the project, and then the proper license file is linked in the javadocs leaving the unused one in the project jar. This is the behavior added by the parent POM, so all projects will have this issue. It needs to be fixed there.

[JanWesterkamp-iJUG]

I just fall about the date again too - good to know this could be handled in a bugfix release.

May be in the future this topic could be solved automatically and/or a unit test prevents this - could be an exerciese to be done in a component spec template project.
Another thing like that in the future would be change of the EFSL version and the potential reflected change of the organisation legal enity (Eclipse Foundation Inc. to Eclipse Foundation AISBL).

[kwsutter]

Looks good, @Emily-Jiang! Just a couple of minor nits on the CCR. Thanks!
Looked closer at the jar files... The javadoc jar file contains the Apache license and the EFSL license, which are okay. But, it also contains the EF TCK license? That should not be part of the javadoc jar file. I don't think this update is a requirement for a respin, but the TCK license should be removed. Open an issue/pr to clean this up after the release.
On a similar vein, the TCK Javadoc jar file contains the EFSL, which doesn't seem right. I think this EFSL should be removed from the TCK Javadoc jar file. Just include this with the issue/pr you create for the previous comment.

This was done on purpose to simplify unpacking the resources. Basically, we have a single JAR with all the resources that are unpacked to the project, and then the proper license file is linked in the javadocs leaving the unused one in the project jar. This is the behavior added by the parent POM, so all projects will have this issue. It needs to be fixed there.

Okay... Seems a bit odd since simply grabbing one of the jar files and unzipping it produces multiple License files. A casual observer wouldn't know which to apply. You mentioned that the problem "needs to be fixed there". Can someone open an issue to get it resolved at the top-level project? Thanks!

[radcortez]

Okay... Seems a bit odd since simply grabbing one of the jar files and unzipping it produces multiple License files. A casual observer wouldn't know which to apply. You mentioned that the problem "needs to be fixed there". Can someone open an issue to get it resolved at the top-level project? Thanks!

You are correct. When I was adding that, I only worried from the javadoc html perspective, so when browsing the javadocs it links to the correct license. No worries, I'll have a look into it.