Scott M Stark

I would order the priority to match those specifications that are currently being targeted for the core profile. I think there is some confusion/concern that there is going to be...

2.2 release plan https://projects.eclipse.org/projects/ee4j.interceptors/releases/2.2

+1 on a requirement for exposing the component and platform/profile version. -1 on any additional JNDI binding as frankly those should be deprecated. I suggest we create an issue for...

Yes, given that there are no details other than a statement that a container must provide a bean with type, java.security.Principal, it makes sense to have this specified in the...

So to date the Jakarta TCKs and platform specs only deal with the existence of the specs that make up the profile or platform or a greater superset. Subsetting is...

The copy/paste error has been corrected and the configuration of the CDI scope/qualifier is based on the extension point as proposed in https://github.com/jakartaee/persistence/pull/566 that @lukasj suggested.

The PR has been updated with the outstanding suggestions. At this point I think it is worthwhile to merge the PR and then iterate on it as we develop the...

@edburns from the https://jakarta.ee/committees/specification/versioning/ process, we need to make a statement on the deprecation of `@Resource` and `@Resources` on the common-annotations feature, ideally with `@Deprecation` on the API/javadoc which probably...

The problem is how do cross cutting concern specs like CDI, security, transactions, etc. define TCK tests that validate expected behaviors in a given container. For example, all of these...

The Jakarta Commons is a related effort https://projects.eclipse.org/proposals/jakarta-commons