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])

The mailing list URL in the specification is incorrect. It currently reads:

https://dev.eclipse.org/mailman/listinfo/interceptor-api-dev

…but the mailing list in question appears to reside elsewhere. PR coming shortly.

• Organization Name ("Organization") and, if applicable, URL
  Eclipse Foundation
• Product Name, Version and download URL (if applicable)
  Eclipse GlassFish 6.0
• Specification Name, Version and download URL
  Jakarta Interceptors 2.0
• TCK Version, digital SHA-256 fingerprint and download URL
  [Jakarta EE Platform TCK 9.0](https://download.eclipse.org/ee4j/jakartaee-tck/jakartaee9-eftl/promoted/jakarta-jakartaeetck-9.0.0-RC1.zip, SHA-256: 75b2493a117e7f8fe775cc7e2e8a605a203611895091f4bb9aaabed57f813392
• Public URL of TCK Results Summary
  There is no stand-alone TCK for this specification. See Full Platform CTS for results.
  TCK results summary
• Any Additional Specification Certification Requirements
  None
• Java runtime used to run the implementation
  Oracle JDK 1.8.0_251
• Summary of the information for the certification environment, operating system, cloud, ...
  Alpine Linux v3.12
• By checking this box I acknowledge that the Organization I represent accepts the terms of the EFTL.
• By checking this box I attest that all TCK requirements have been met, including any compatibility rules.

This information is from the Weld CDI CCR.

Compatibility Certification Information

• Organization Name ("Organization") and, if applicable, URL:
  
  Red Hat, https://www.redhat.com/
• Product Name, Version and download URL (if applicable):
  
  Weld 6.0.0.Beta1, https://weld.cdi-spec.org/download/
• Specification Name, Version and download URL:
  
  Jakarta Contexts Dependency Injection 4.1
• TCK Version, digital SHA-256 fingerprint and download URL:
  
  https://download.eclipse.org/ee4j/cdi/4.1/cdi-tck-4.1.0-dist.zip,
  
  446029ee1ce694d2a9ae8893d16be7afd7e1c0ed8705064b7095af174cf97ea0
• Public URL of TCK Results Summary:
  
  https://github.com/jakartaredhat/cdi-tck/wiki/Jakarta-CDI-4.1-TCK-Weld-Results-17.md
  https://github.com/jakartaredhat/cdi-tck/wiki/Jakarta-CDI-4.1-TCK-Weld-Results-21.md
• Any Additional Specification Certification Requirements:
  
  Signature tests passed
• Java runtime used to run the implementation:
  
  OpenJDK Runtime Environment Temurin-17.0.4.1+1 (build 17.0.4.1+1)
  OpenJDK Runtime Environment Temurin-21.0.1+12 (build 21.0.1+12-LTS)
• Summary of the information for the certification environment, operating system, cloud, ...:
  
  Darwin Scotts-Mac-Studio.local 21.6.0 Darwin Kernel Version 21.6.0: Thu Nov 9 00:42:05 PST 2023; root:xnu-8020.240.18.705.10~1/RELEASE_ARM64_T6000 arm64
• By checking this box I acknowledge that the Organization I represent accepts the terms of the EFTL.
• By checking this box I attest that all TCK requirements have been met, including any compatibility rules.

Hello; I just noticed this and didn't want it to get lost.

See https://github.com/eclipse-ee4j/interceptor-api/blob/master/spec/src/main/asciidoc/2_interceptor_programming_contract.adoc#timeout-method-interceptor-methods. The example involves calling getInfo() on the timer object returned by InvocationContext#getTimer(), which is of type Object. Hence this won't compile.

I can not download the jar anymore: https://mvnrepository.com/artifact/javax.interceptor/javax.interceptor-api/3.1

I also tried it from Germany and with a proxy from US.

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.

This task is for creating a basic build CI/CD pipeline for this project on Eclipse infrastructure. More information is here: https://ci.eclipse.org/.

In order to prepare this project to engage in specification work, we need to convert it into a specification project as defined by the Eclipse Foundation Specification Process (EFSP). As part of this work, we will change the project name and the scope.

We'll use this issue to capture the work that needs to be done as part of this effort.

• Resolve #30
• Resolve #29
• Successful complete a restructuring review
• Designate the project as a specification project of the Jakarta EE Working Group
• Change project name

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/

Instructions

• Update text files
• Generate "boilerplate" specification project
• Make a staging release
• Generate Stand-alone TCK test results
• Create a PR to jakartaee/specifications repository
• Update the Jakarta EE API jar by submitting a PR to the jakartaee-api project

See here for detailed instructions.

• Uptake new Eclipse versions of dependencies (if any). Use GlassFish 5.1 Release Tracker wiki to find components versions to use.

• Release to OSSRH staging repository

• Update GlassFish 5.1 Release Tracker with released version number.

as is required and documented in https://www.eclipse.org/projects/handbook/#legaldoc

The question in $title came up recently and I failed to find any solid mention in interceptors specificatio and javadoc that would be either for or against the usage of repeating annotations as interceptor bindings.

I know that, for instance, Weld (CDI impl) allows you to do that. However, this doesn't seem to be backed by any specification. I'd be nice to have it written somewhere. WDYT?

Hello,

recently we came across and interesting question which revolves around interception of default methods.

Currently, the specification doesn't really mention default methods. Therefore you can only imply what it should behave like.
One not so obvious aspect is inheritance rules for interceptor bindings in conjunction with default methods.
According to what the spec says right now, you do not inherit bindings from interfaces. However, that means that the only way to intercept a default method is to use a class-level binding on the implementing class.

I have seen this disputed by users (of Weld and Quarkus, both of which support default method interception) several times and I have to give them some credit for it. It is indeed not really intuitive. It also takes away some customization power because you cannot use method-level binding with default methods; you have to intercept all methods of the implementing class.

I realize changing this presents backward compatibility issues and I am not saying we should go that way. However, I'd like to hear some more opinions on how people perceive this, if the spec should perhaps mention this and what they think could/should be done in this regard.

Background information:
https://waynebeaton.wordpress.com/2019/04/04/renaming-java-ee-specifications-for-jakarta-ee/

Checklist:

• GitHub
• README file
• CONTRIBUTING file
• Eclipse Project under https://projects.eclipse.org/projects/ee4j

This is a place holder issue for Pull request from javaee/javax.interceptor#3

Compatibility Certification Information

• Organization Name ("Organization") and, if applicable, URL:
  
  Red Hat, https://www.redhat.com/
• Product Name, Version and download URL (if applicable):
  
  Weld 5.0.0.CR1, https://weld.cdi-spec.org/download/
• Specification Name, Version and download URL:
  
  Jakarta Interceptors 2.1
• TCK Version, digital SHA-256 fingerprint and download URL:
  
  https://download.eclipse.org/ee4j/cdi/4.0/cdi-tck-4.0.0-dist.zip,
  
  7671d6895eb57b74b52e46b63adfeb57adf965dd91efc673db21a781fedc452f
• Public URL of TCK Results Summary:
  
  https://github.com/jakartaredhat/cdi-tck/wiki/Jakarta-CDI-4.0-TCK-Results
• Any Additional Specification Certification Requirements:
  
  Signature tests passed
• Java runtime used to run the implementation:
  
  OpenJDK Runtime Environment Temurin-11.0.13+8 (build 11.0.13+8)
• Summary of the information for the certification environment, operating system, cloud, ...:
  
  EF CI environment Linux basic-wfdp4 5.14.14-200.fc34.x86_64 #1 SMP Wed Oct 20 16:15:12 UTC 2021 x86_64 GNU/Linux
• By checking this box I acknowledge that the Organization I represent accepts the terms of the EFTL.
• By checking this box I attest that all TCK requirements have been met, including any compatibility rules.

Due, probably primarily, to the history of the Interceptors specification, the specification mentions "business method" 16 times but never defines it.

"Business method" is a well-defined term in the Jakarta EJB specification, from whose ancestor the original Interceptors specification evolved. I suspect that the definition found there is the one that should be included here.

This is a place holder issue for Pull request from javaee/javax.interceptor#2

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.

If there are no objections I'd like to move this repo soon.

• Integrate to Eclipse GlassFish
• Pass all CTS/TCK tests

#13 must be finished before starting working on this task.

All current API libraries shipped must be distributed to Maven Central under a sub-package of the jakarta groupId. Before the first release Maven coordinates of this project must be changed as it's described here.

• Specification Committee Member...

• creates an issue in the specification project that includes the following checklist for the specification project team:

• Interceptors Specification Project Team...

• promotes api staging release promotes the specification api jars to maven central. An example release job script can be found here https://wiki.eclipse.org/MavenReleaseScript.
• go through the merged jakarta.ee specification website page to verify all the links are valid.
• approve the compatibility request.
• The compatible implementation project/vendor MUST send an email to [email protected] for approval of the compatible implementation for trademark usage.
• merge any final release branch as appropriate for the branch management for the project.

This is a place holder issue for Pull request from javaee/javax.interceptor#1

To test Jakarta EE 8 compatibility we need to create a Jenkins job on project's Cloud Jenkins instance formally testing the API against the relevant TCK and as needed, relevant CTS subset tests.

For projects that do not already have automated testing, there is provided parameterized Jenkins job that can be invoked to perform these tests. User provides a link to an Eclipse GlassFish test build and sets the test sub-set parameters:

• For CTS -- https://ci.eclipse.org/jakartaee-tck/job/jakartaeetck-certification/
• For Stand-alone TCKs -- https://ci.eclipse.org/jakartaee-tck/job/standalonetck-certification/

Additional instructions and guidance for using and directly running TCKs is available on this wiki. Also in the jakartaee-tck project repository.

• Organization Name ("Organization") and, if applicable, URL
  Eclipse Foundation
• Product Name, Version and download URL (if applicable)
  Eclipse GlassFish 5.1
  Includes Interceptors 1.2.3
• Specification Name, Version and download URL
  Jakarta Interceptors 1.2
• TCK Version, digital SHA-256 fingerprint and download URL
  Jakarta EE Platform CTS 8.0, SHA-256: 847c80c9c80bea4682006f186292b68acdd0ce9b239d998856c3a379c3a7be50
• Public URL of TCK Results Summary
  There is no stand-alone TCK for this specification. See Full Platform CTS for results.
  TCK results summary
• Any Additional Specification Certification Requirements
  None
• Java runtime used to run the implementation
  Oracle JDK 1.8.0_191
• Summary of the information for the certification environment, operating system, cloud, ...
  Linux Centos 7
• By checking this box I acknowledge that the Organization I represent accepts the terms of the EFTL.
• By checking this box I attest that all TCK requirements have been met, including any compatibility rules.

A requirement for the EE10 release is for API jars to include a proper module-info.class. Please create a service release to include this.

jakartaee/platform#421

I went looking for the spec doc the other day.
Turns out that the doc on website is 5 pages long and contains licences plus first paragraph of chapter one and that's it (for both, 1.2 and 2.x).
Same goes for when you try to build the doc from repo, at least on master branch.

This was brought up in the CDI project as the following issue:
jakartaee/cdi#592

The basic idea is to add a series of getInterceptorBindings() default methods to the jakarta.interceptors.InvocationContext interface.

We need the 3.0.0 final release to be able to release the 2.2.0 final of interceptors

Jakarta release of this API has wrong value of OSGi Bundle-SymbolicName in MANIFEST.MF.
Current value is javax.interceptor-api but expected value could be jakarta.interceptor-api .

Tasks to complete the release:

• promotes api staging release promotes the specification api jars to maven central. An example release job script can be found here https://wiki.eclipse.org/MavenReleaseScript.
• go through the merged jakarta.ee specification website page to verify all the links are valid.
• if XML Schemas are published on https://jakarta.ee/schemas, send a PR to update the status from Draft to Final.
• approve the compatibility request.
• The compatible implementation project/vendor MUST send an email to [email protected] for approval of the compatible implementation for trademark usage.
• merge any final release branch as appropriate for the branch management for the project.

The interceptor api declared 2 deps common-annotations and ejb in the pom.xml,
but none of them has been imported, so can we remove it?
https://github.com/eclipse-ee4j/interceptor-api/blob/8eb1e608ad81c06ddfd147a077c06cad2b46f9a2/pom.xml#L322-L334

➜  interceptor-api git:(EE4J_8) find . -name \*.java -exec grep "import javax" {} \;
➜  interceptor-api git:(EE4J_8) 

Update the scope statement for the project: https://projects.eclipse.org/projects/ee4j.jakartaee-platform/governance

See https://docs.google.com/spreadsheets/d/1FPLjo_DJDOQngVtdrYgaDk98d9NBG-0ODgdmOG3LOsI/edit?usp=sharing for examples.

Passing Release Review is a required step before making a first public release. Deadline for passing the review is Nov 30th, 2018. Release review takes some time to complete, so it makes sense initiating it as soon as possible.

• Start Release Review
• Update Release Review Tracker

Additional information:

• How to submit a release review
• Eclipse Handbook

We need to create a release CI/CD pipeline for this project.

Use these documents as a reference:

• How to release the first Eclipse version of projects
• JSONP release job
• Release job on the new cloud infra

Update Eclipse GlassFish to use the new version of your API (and implementation, if applicable) by submitting a PR to GlassFish.

Although a new version of GlassFish will not be released for Jakarta EE 8, we hope to release an update sometime later.

Last CTS runs indicate no failures in this component. It's time to make a public release. Before the release make sure that Eclipse Release Review is passed and all dependencies have been released.