jakartaee / inject-spec Goto Github PK

Per the discussions on the Spec Committee and Platform Dev mailing lists, it's been discovered that many of the Javadoc and Spec references to the EFSL need updating. Please reference the following required updates and keep them in mind as your Spec Project is updating the files for Jakarta EE 9.

Note: Some Spec Projects have already started or even completed these updates. If so, just kindly return/close this Issue. Thanks!

Required EFSL updates for Javadoc

For javadoc, the EFSL.html located in src/main/javadoc/doc-files should be modified as follows:

• the <<url to this license>> needs to be replaced with efsl.php link[1]
• the [title and URI of the Eclipse Foundation specification document] needs to be replaced with the Specification Name and URL (Reference [2] for an example.)
• The javadoc footer copyright year needs to be updated to 2018, 2020 as defined in the pom.xml

Required EFSL updates for Specifications

For specification, the license-efsl.adoc located in src/main/asciidoc should be modified as follows:

• Update copyright year to 2018, 2020 from 2019. Add link to EFSL.
• the <<url to this license>> needs to be replaced with efsl.php link[1]
• the [title and URI of the Eclipse Foundation specification document] needs to be replaced with the Specification Name and URL (Reference [2] for an example.)

[1] https://www.eclipse.org/legal/efsl.php
[2] https://jakarta.ee/specifications/enterprise-beans/4.0/

Is your feature request related to a problem? Please describe.
Jakarta EE 9 is the next major release, with the main focus of moving from the javax namespace to the jakarta namespace.

Describe the solution you'd like
This issue will be used to track the progress of this work effort via the Jakarta EE 9 Project board.

Additional context
Jakarta EE Specification Process
Eclipse Project Handbook
Eclipse Release Record for Jakarta EE 9

ToDo

• Create Eclipse Release Record in your respective Jakarta Specification Project.
  Most Component Release Records will just reference the Jakarta EE 9 Platform Release Plan. But, if your Component deviates at all from the Platform Release Plan, then a description of the changes will be required in the Release Record.
• Initiate a ballot for your Jakarta Release Record/Plan.
  Again, if your component is only doing the required minimum as defined by the Jakarta EE 9 Platform Release Plan, then no separate ballot is required. You are already approved. But, if your component deviates from the Platform Release Plan, then you will need to initiate your own ballot as defined by the Jakarta EE Specification Process.
• Jakarta-ize your Specification document (if applicable)
  Many of the Jakarta EE components now have the source for their Specification documents. It is strongly recommended that these Specification documents are properly updated to represent Jakarta EE instead of Java EE. Some helpful instructions are documented here.
• javax -> jakarta Spec updates
  If your component has Specification source, then all javax package references need to be updated to use jakarta package references.
• javax -> jakarta API updates
  Your component APIs need to move from using the javax namespace to using the jakarta namespace.
• Release Candidate (RC) of Jakarta API in Maven Central
  A Release Candidate of your component API should be pushed to Maven Central as soon as humanly possible. This will allow other dependent components to utilize your APIs as they are updating their APIs. Multiple revisions of these Release Candidate APIs are allowed (and probably expected) during the development cycle.
• javax -> jakarta TCK updates
  Your component TCK needs to be updated to use the jakarta namespace.
• javax -> jakarta Compatible Implementation updates
  Your compatible implementation that will be used to demonstrate completeness of the Specification needs to be updated to use the jakarta namespace.
• Final Jakarta API available in Staging Repo
  When ready, your final version of the API needs to be staged to get ready for the PR review and approvals.
• Draft Specification and Apidoc PRs ready for review
  Like we did for Jakarta EE 8, draft PRs need to be created and reviewed in preparation for the final ballots.
• Release Review Ballot started
  Each Jakarta EE component will need to initiate a separate Release Review ballot after proper reviewing has completed. To be clear, there will not be a blanket Release Review for all of Jakarta EE 9 like we did for the Plan Review. Each component needs a separate Release Review.

• [*] Organization Name ("Organization") and, if applicable, URL
  Red Hat, Inc., http://redhat.com
• [*] Product Name, Version and download URL (if applicable)
  Weld 2.4.8.Final, https://weld.cdi-spec.org/download/
• [*] Specification Name, Version and download URL
  Jakarta Dependency Injection 1.0
• [*] TCK Version, digital SHA-256 fingerprint and download URL
  http://download.eclipse.org/jakartaee/dependency-injection/1.0/jakarta.inject-tck-1.0-bin.zip, b679bac9b1057df894753892a880ba6ade530607dd811157106ed767aa26481f
• [*] Public URL of TCK Results Summary
  https://github.com/jakartaredhat/weld-inject-tck/wiki/Jakarta-Dependency-Injection-1.0-TCK-Results
• [*] Java runtime used to run the implementation
  OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_212-b03)
• [*] Summary of the information for the certification environment, operating system, cloud,
  iMacPro, OSX 10.14.4
• [*] By checking this box I acknowledge that I accept the terms of the EFTL.
• [*] By checking this box I attest that all TCK requirements have been met, including any compatibility rules.

Create/Update CONTRIBUTING files

Per input from the Eclipse EMO, each Specification Project needs to ensure that a CONTRIBUTING.md or CONTRIBUTING.adoc file exists in each specification-related repository maintained by Specification Projects.
In addition, the CONTRIBUTING.md or CONTRIBUTING.adoc file needs to include the following text:

## Eclipse Development Process

This Eclipse Foundation open project is governed by the Eclipse Foundation
Development Process and operates under the terms of the Eclipse IP Policy.

The Jakarta EE Specification Committee has adopted the Jakarta EE Specification
Process (JESP) in accordance with the Eclipse Foundation Specification Process
v1.2 (EFSP) to ensure that the specification process is complied with by all
Jakarta EE specification projects.

* https://eclipse.org/projects/dev_process
* https://www.eclipse.org/org/documents/Eclipse_IP_Policy.pdf
* https://jakarta.ee/about/jesp/
* https://www.eclipse.org/legal/efsp_non_assert.php

Please do this at your earliest convenience.
Thank you!

-- EE4J PMC ([email protected])

• Product Name, Version and download URL (if applicable)
  Weld 4.0.0.Alpha2, https://weld.cdi-spec.org/download/
• Specification Name, Version and download URL
  Jakarta Dependency Injection 2.0, https://jakarta.ee/specifications/dependency-injection/2.0/
• TCK Version, digital SHA-256l fingerprint and download URL
  https://download.eclipse.org/ee4j/cdi/inject/2.0/jakarta.inject-tck-2.0.1-bin.zip
  7853d02d372838f8300f5a18cfcc23011c9eb9016cf3980bba9442e4b1f8bfc6
• Implementation runtime Version(s) tested
  Weld 4.0.0.Alpha2
• Public URL of TCK Results Summary
  https://github.com/jakartaredhat/weld-inject-tck/wiki/Jakarta-Dependency-Injection-2.0-TCK-Results
• Java runtime used to run the implementation
  Java HotSpot(TM) 64-Bit Server VM (build 25.202-b08, mixed mode)
• Summary of the information for the certification environment, operating system, cloud, ...
  Eclipse CI build Linux amd64 host
• By checking this box I acknowledge that I accept the terms of the EFTL.
• By checking this box I attest that all TCK requirements have been met, including any compatibility rules.

In the steering committee we voted to moved all specification projects from eclipse-ee4j to jakartaee. As such this repo should move to in due time.

Moving is fairly automatic, and redirects will be automatically put in place from the current location here to the new location.

Extra from: https://www.eclipse.org/lists/jakarta.ee-spec/msg02073.html

"We voted on it in 2019 and then in 2020 we added it explicitly to our 2021 plan and voted on that plan. I think we just need to start executing. I sent about 30 emails like the following in an attempt to add some shape to it and kick off the move in the spec projects.

• https://www.eclipse.org/lists/jakartaee-platform-dev/msg02940.html
• https://www.eclipse.org/lists/messaging-dev/msg00028.html
• https://www.eclipse.org/lists/jakartaee-tck-dev/msg01417.html
• https://www.eclipse.org/lists/ejb-dev/msg00264.html
  "

Also note that many projects have indeed moved: https://github.com/jakartaee/

While the other specs requires to use the provided binary, the Javadoc of the jakarta.inject allows to implement as a compile time option:

An injector that uses compile-time code generation may not even have its own run time representation. 1

So it is possible to certify an implementation that uses compile time injection? It would be needed to compile the sources provided by the TCK and run the tests with the compiled version.

Or is it not legal to certify a compile-time DI?

Thanks!