DisposalMethodDefinitionTest should detect an incorrect definition of DisposalNonBean on deploy.

If there is no producer method or producer field declared by the bean class that is assignable to the disposed parameter of a disposer method, the container automatically detects the problem and treats it as a definition error.

Currently EE10 is targeting allowing or even requiring that a TCK can be run under Java SE 17. Currently the embedded set of tests pass, but when running against the wildfly23 preview, there is a problem loading the arquillian wildly container configuration:

✏️ [starksm@Scotts-iMacPro#1531]-(JavaVirtualMachines)
└> $JAVA_HOME/bin/java -version
openjdk version "11.0.7" 2020-04-14 LTS
OpenJDK Runtime Environment Zulu11.39+15-CA (build 11.0.7+10-LTS)
OpenJDK 64-Bit Server VM Zulu11.39+15-CA (build 11.0.7+10-LTS, mixed mode)
✏️ [starksm@Scotts-iMacPro#1532]-(starksm64-core)-[git://master ✔]-
└> mvn verify -f jboss-tck-runner/pom.xml                  
[INFO] Scanning for projects...
[INFO] 
[INFO] Running TestSuite
...
INFO: Invoke StereotypeWithAlternativeSelectedByPriorityTest.testStereotypeAlternativeIsEnabled: 15/1,808 Failed tests: 0 (12)
[Utils] [ERROR] [Error] java.lang.RuntimeException: Could not create new instance of class org.jboss.arquillian.test.impl.EventTestRunnerAdaptor
	at org.jboss.arquillian.test.spi.SecurityActions.newInstance(SecurityActions.java:146)
	at org.jboss.arquillian.test.spi.SecurityActions.newInstance(SecurityActions.java:89)
	at org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder.build(TestRunnerAdaptorBuilder.java:49)
	at org.jboss.arquillian.testng.Arquillian$1.initialValue(Arquillian.java:58)
	at org.jboss.arquillian.testng.Arquillian$1.initialValue(Arquillian.java:55)
	at java.base/java.lang.ThreadLocal.setInitialValue(ThreadLocal.java:195)
	at java.base/java.lang.ThreadLocal.get(ThreadLocal.java:172)
	at org.jboss.arquillian.testng.Arquillian.arquillianArgumentProvider(Arquillian.java:240)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:133)
	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:77)
	at org.testng.internal.MethodInvocationHelper.invokeMethodNoCheckedException(MethodInvocationHelper.java:46)
	at org.testng.internal.MethodInvocationHelper.invokeDataProvider(MethodInvocationHelper.java:146)
	at org.testng.internal.Parameters.handleParameters(Parameters.java:798)
	at org.testng.internal.Parameters.handleParameters(Parameters.java:740)
	at org.testng.internal.ParameterHandler.handleParameters(ParameterHandler.java:59)
	at org.testng.internal.ParameterHandler.createParameters(ParameterHandler.java:38)
	at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:791)
	at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:146)
	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
	at org.testng.TestRunner.privateRun(TestRunner.java:794)
	at org.testng.TestRunner.run(TestRunner.java:596)
	at org.testng.SuiteRunner.runTest(SuiteRunner.java:377)
	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:371)
	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:332)
	at org.testng.SuiteRunner.run(SuiteRunner.java:276)
	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53)
	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96)
	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1212)
	at org.testng.TestNG.runSuitesLocally(TestNG.java:1134)
	at org.testng.TestNG.runSuites(TestNG.java:1063)
	at org.testng.TestNG.run(TestNG.java:1031)
	at org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:284)
	at org.apache.maven.surefire.testng.TestNGXmlTestSuite.execute(TestNGXmlTestSuite.java:75)
	at org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:119)
	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:428)
	at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:162)
	at org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:562)
	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:548)
Caused by: java.lang.reflect.InvocationTargetException
	at jdk.internal.reflect.GeneratedConstructorAccessor52.newInstance(Unknown Source)
	at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
	at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:480)
	at org.jboss.arquillian.test.spi.SecurityActions.newInstance(SecurityActions.java:144)
	... 43 more
Caused by: java.lang.IllegalArgumentException: No container or group found that match given qualifier: wildfly-23

While running under Java SE 11 produces:

✏️ [starksm@Scotts-iMacPro#1543]-(starksm64-core)-[git://master ✔]-
└> $JAVA_HOME/bin/java -version
java version "11.0.7" 2020-04-14 LTS
Java(TM) SE Runtime Environment 18.9 (build 11.0.7+8-LTS)
Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.7+8-LTS, mixed mode)
✏️ [starksm@Scotts-iMacPro#1544]-(starksm64-core)-[git://master ✔]-
└> mvn verify -f jboss-tck-runner/pom.xml
[INFO] Scanning for projects...
[INFO] 
[INFO] ----------------< org.jboss.weld:weld-jboss-runner-tck >----------------
[INFO] Building CDI TCK runner (4.0) for Weld (WildFly) 4.0.2-SNAPSHOT
...
[INFO] Tests run: 1218, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 34.148 s - in TestSuite
[INFO] 
[INFO] Results:
[INFO] 
[INFO] Tests run: 1218, Failures: 0, Errors: 0, Skipped: 0
[INFO] 
[INFO] 

In looking at current core tests failures related to missing bean defining annotations, I came across the org.jboss.cdi.tck.tests.implementation.builtin.metadata.broken.injection.decorated package tests. These are using @decorated and validating the requirements around that qualifier.

Another test is org.jboss.cdi.tck.tests.implementation.builtin.metadata.broken.injection.BuiltinDecoratorInjectionTest

The following file does not reference the Jakarta EE 9 schema https://github.com/eclipse-ee4j/cdi-tck/blob/master/impl/src/main/resources/org/jboss/cdi/tck/tests/implementation/simple/resource/persistenceContext/persistence.xml

Issue to track a test for the new BeanConfigurator.priority jakartaee/cdi#532 change

Breaking up the sets of tests into separate categories, portable extension based tests need to added to the CDI_FULL test group.

The org.jboss.cdi.tck.tests.implementation.simple.resource.env.EnvInjectionTest#testResourceBeanTypes is validating the number of types seen in the Bean type with the Greeting annotation. It is expecting a total of four types, which through Java SE 11 would include:
java.lang.Boolean
java.io.Serializable
java.lang.Comparable
java.lang.Object

In Java SE 12 the java.lang.Boolean class includes an additional java.lang.Constable interface, and so this test fails when run under a JVM later than Java SE 11. The test should just compare the expected types to what are seen on the JVM local Boolean.class to avoid JVM version dependencies.

Currently, the project fetches some dependencies from jboss repositories which is fine.

However, it declares the repo using http instead of https which becomes an issue with newer Maven (3.8.1+).
Maven changed their default behavior because of a CVE issue, see also https://maven.apache.org/docs/3.8.1/release-notes.html

Any build (TCK or an impl using them) with the above stated maven version will end with something like;

Failed to read artifact descriptor for org.jboss.test-audit:jboss-test-audit-impl:jar:1.1.4.Final: Could not transfer artifact org.jboss.test-audit:jboss-test-audit-impl:pom:1.1.4.Final from/to maven-default-http-blocker (http://0.0.0.0/): Blocked mirror for repositories: [jboss-public-repository-group (http://repository.jboss.org/nexus/content/groups/public, default, releases)]

We should be able to simply switch over to https declaration to fix this - I will issue respective PRs shortly.

Note that this will not only break latest master but also 3.x and 2.x making the build fail - we should probably issue a fix into all versions and possibly cut a release?
Otherwise any consumers need to either specify a mirror (which cannot be declared in pom.xml, it has to reside in settings.xml) or they would have to re-define the repository with the same <id> inside their POMs.

Test coverage issue for jakartaee/cdi#521

We should be able to use some tests that are already existing in Weld.

CDI Lite comes with a new language model abstraction that needs to be tested.
As this API is a potential subject for extraction into a separate module, tests should be written in some standalone manner.

Based on today's CDI call, we want to revert #256, and then redo it in smaller stages based on small blocks of packages of tests after first applying the cdi-full group to tests based on:

• #262
• #263
• #264
• #265
• #289

We also want to move the cdi-full tests into a new package to separate them from the lite tests as this regrouping is done. The issue for that is #272.

This only concerns TCK tests that require EE container (WFLY, GF, Liberty,...) to run.
I have cobbled together a WFLY with CDI 4 and Weld 5 snapshot and I am running it against TCKs. This is uncovering some (roughly) 200 tests that are failing. Most failures will be just missing annotations because of empty beans.xml or other trivial changes.

I am planning to look into it and send a PR within a day or two.

CDI API has version 4.0.0.x
CDI TCK has version 4.1.0.x

This needs to be aligned and as discussed on the meeting today (23.11.), we agreed that having TCKs as 4.1.0 was a mistake, not intention. Therefore, we need to change the current project version from 4.1.0-SNAPSHOT to 4.0.0-SNAPSHOT and any subsequent releases should contain version 4.0.0 instead.

This isn't a big deal as all version 4 releases up until now were only Alphas.

I think this repository needs a license file in the TLD. Please consider adding the appropriate documentation.

CDI API 4.0.0.Alpha1 removed some long deprecated methods.

CDI TCK are still using those (BM.fireEvent(), @New tests etc) so we need to rework those tests and cut a release which can be consumed by implementors.

With the non-Lite tests moved under the full package and labelled with the cdi-full test group, the Weld jboss-tck-runner emedded tests show the following failure count due to missing bean defining annotations:

[ERROR] Tests run: 1423, Failures: 385, Errors: 0, Skipped: 245

The next step in #273 is to add the missing bean defining annotations to obtain a clean run of the core tests under Weld.

@starksm64 all previous CDI TCK releases were available as artifacts in maven central.
Would it be possible to keep it that way under jakarta?

Having a ZIP released is nice but most projects run simply on maven artifacts and having a release which is not downloadable is awkward.

I am talking about latest TCK 2.0.6 release which is only available as ZIP. Moving Weld to use Jakarta GAVs all the way, I OFC encountered this. I'd have to re-do the TCK testing infrastructure which up to this point relied on TCKs being a downloadable artifact and as such bringing in a bunch of required dependencies.

If you want to run the TCKs now, you'd need to get the release, unpack it and install it to local maven repository. That's viable if you do a one time check but becomes really bothersome if you are running TCKs as a part of regular testsuite.

While there was a 2.0.6.SP1 release to maven, we did not update the Jakarta EE 8 TCK, so that needs to happen as well.

Breaking up the sets of tests into separate categories, @ Decorator based tests need to added to the CDI_FULL test group.

If jakartaee/cdi#577 we need to review all tests using this scope and whether they have Full category.
A quick grep shows a bunch of them, but not too many, which are possible candidates for this move.

Currently, we have no coverage for @SkipIfPortableExtensionPresent - an annotation that can be used when portable extensions and build compatible extensions co-exist in a CDI Full environment.

We should add a simple smoke test for it.
Note that this will have to belong to a Full category.

The way the test will look will be affected by resolution of jakartaee/cdi#585

Testing with Java SE 17 (early access) to run https://download.eclipse.org/jakartaee/cdi/3.0/cdi-tck-3.0.1-dist.zip tests + WildFly master is seeing failure:

[ERROR] org.jboss.cdi.tck.tests.implementation.simple.resource.env.EnvInjectionTest.testResourceBeanTypes  Time elapsed: 0.04 s  <<< FAILURE!
java.lang.AssertionError
	at deployment.dedc6d5ace7963e7119a9865eca6c1a74203870.war//org.jboss.cdi.tck.tests.implementation.simple.resource.env.EnvInjectionTest.testResourceBeanTypes

This is already resolved for upstream issue #238.

Needed action:

• Please add challenge label for this issue.
• Within two weeks, please accept this challenge or reject it.
• If the challenge is accepted, please exclude the org.jboss.cdi.tck.tests.implementation.simple.resource.env.EnvInjectionTest.testResourceBeanTypes test to be in the cdi-tck-3.0.2-dist.zip or in the next cdi-tck-3.0.*-dist.zip release.

With new CDI version, we want to change default empty beans.xml perception from ALL discovery to ANNOTATED discovery.
This requires a new TCK test - I will prepare a PR with it.

Add a new parent org.jboss.cdi.tck.tests.full package to use as the root for all CDI tests with the cdi-full group. This should be done as test group is updated.

As part of jakartaee/cdi#583 I encountered several parts on the lang model TCK that were problematic with JDK 16 while passing with JDK 11.

This concerns any runtime CDI Full implementation (in this case Weld) that will use Java reflection as a basis for the lang model.

An example of the issue is a method with receiver containing generics:

    public void methodWithReceiver(@AnnReceiver1 ReceiverOnGenericClass<T> this) {
    }

When accessed via reflections. with: ReceiverOnGenericClass.class.getDeclaredMethod("methodWithReceiver").getAnnotatedReceiverType().getType()

this will return:

• with JDK 11 - {Class} "class org.jboss.cdi.lang.model.tck.ReceiverOnGenericClass"
• with JDK 16 - {ParameterizedTypeImpl} "org.jboss.cdi.lang.model.tck.ReceiverOnGenericClass<T>"

This then leads to conflicting expectationd in the lang model interpretation and the TCK assertions.

I have found three cases which are problematic with different JDKs; I'll send a PR that changes the TCK to accept both variants with a TODO comment explaining it.
As a side note, none of them affects CDI functionalities.

According to the spec:

If a producer field is annotated @Inject, the container automatically detects the problem and treats it as a definition error.

I would assume that this class should throw an error on deploy of BeanManagerTest:

@Dependent
public class Snake {

    @Inject
    @Produces
    int age;

    public Snake(String name) {
    }

}

As per the discussed 4.0 CDI changes, the default discovery mode for an empty beans.xml file needs to change from ALL to ANNOTATED.

org.jboss.cdi.tck.tests.event.metadata.EventMetadataTest

Micronaut will return a custom instance of ParameterizedType which is not going to match the reflection implementation.

Changes done in jakartaee/cdi#549 remove the affect of present/absent version attribute of beans.xml on chosen bean discovery mode.
I recall that I saw at least one test that verifies this. We should look that up and adjust it.

These tests use @Test(groups = CDI_FULL), but are not in the full package. We should move them.

Provided jakartaee/cdi#495 gets accepted, we will need test coverage for it.

Namely we need tests that:

• Use @Stereotype with @Priority to enable interceptor
• Use @Stereotype with @Priority to enable decorator (Full only!)
• Use @Stereotype with @Priority to enable alternative
• Have a @Alternative bean declaring two stereotypes both of which have @Priority and the bean itself doesn't declare @Priority
• Have a @Alternative bean declaring two stereotypes both of which have @Priority and the bean itself does declare @Priority
• Transitive stereotype scenario (stereotypes declaring stereotypes) where all stereotypes declare @Priority and assertion that the most specific value is taken
• ??

EDIT: TCKs should only cover the case of @Stereotype with @Priority used to enable alternatives as that is the main goal of this addition.

The current approach that attempts to reload classes generated from annotation processing is producing class loading issues, so we need to use a two pass approach that allows the test source to be passed to an annotation processor via the SourceProcessor SPI, and then run the tests against the resulting updated tests.

Just checking out the project and running mvn clean install with JDK 11 gives:

[WARNING] 
java.lang.NoClassDefFoundError: javax/annotation/Generated
    at org.jboss.test.audit.generate.SectionsClassGenerator.generateSource (SectionsClassGenerator.java:121)
    at org.jboss.test.audit.generate.SectionsClassGenerator.generateToFile (SectionsClassGenerator.java:196)
    at org.jboss.test.audit.generate.SectionsClassGenerator.main (SectionsClassGenerator.java:83)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
    at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:566)
    at org.codehaus.mojo.exec.ExecJavaMojo$1.run (ExecJavaMojo.java:282)
    at java.lang.Thread.run (Thread.java:834)
Caused by: java.lang.ClassNotFoundException: javax.annotation.Generated
    at java.net.URLClassLoader.findClass (URLClassLoader.java:471)
    at java.lang.ClassLoader.loadClass (ClassLoader.java:589)
    at java.lang.ClassLoader.loadClass (ClassLoader.java:522)
    at org.jboss.test.audit.generate.SectionsClassGenerator.generateSource (SectionsClassGenerator.java:121)
    at org.jboss.test.audit.generate.SectionsClassGenerator.generateToFile (SectionsClassGenerator.java:196)
    at org.jboss.test.audit.generate.SectionsClassGenerator.main (SectionsClassGenerator.java:83)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
    at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:566)
    at org.codehaus.mojo.exec.ExecJavaMojo$1.run (ExecJavaMojo.java:282)
    at java.lang.Thread.run (Thread.java:834)

This is not very friendly and we should find the cause and fix it.

Breaking up the sets of tests into separate categories, first @interceptors based tests need to added to the CDI_FULL test group.

After pulling in the latest updates I'm seeing the following test failure in the org.jboss.cdi.tck.tests.full.* tests:

[ERROR] Tests run: 470, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 24.854 s <<< FAILURE! - in TestSuite
[ERROR] org.jboss.cdi.tck.tests.full.event.observer.extension.BeanManagerObserverNotificationTest.fireEvent  Time elapsed: 0.073 s  <<< FAILURE!
org.testng.TestNGException: 

Cannot inject @Test annotated Method [fireEvent] with [class org.jboss.cdi.tck.tests.full.event.observer.extension.Giraffe, class [Ljava.lang.annotation.Annotation;].
For more information on native dependency injection please refer to https://testng.org/doc/documentation-main.html#native-dependency-injection

The problem is the addition of the @test(groups = CDI_FULL) at the class level is causing all public methods to be treated as test methods. This class only has one test, so moving the groups setting to that test fixes the problem.

As per the Jakarta EE 9 release plan any CDI tests that reference the below mentioned optional technologies should be removed or made optional.:

Specifications Added to Jakarta EE 9

The following specifications previously part of Java SE 8 will be added to Jakarta EE 9 either as required or optional specifications as indicated and MUST be moved to the jakarta namespace.

    Jakarta Activation (Required)
    Jakarta XML Binding (Optional)
    Jakarta XML Web Services (Optional)
    Jakarta Web Services Metadata (Optional)
    Jakarta SOAP with Attachments (Optional)

Note that this impacts both Full Platform + Web Profile.

The TCK has various tck-audit-*.xml files that conform to the http://jboss.com/products/weld/tck/audit schema that providing a mapping from specification assertions and associated text to the actual unit test. This has gotten out of date, and it should be a goal to bring these files back into alignment with the specifications.

With the move to asciidoc, it may be possible to create a converter that allows for the generation of the audit files.

When the JarArchiveBuilder was introduced to test cdi-lite specific behavior, it added a call to processSources(archive) to attache the test source files to the archive for use in build time processing. It was not added to WebArchiveBuilder because it was not clear if we would switch all cdi-lite tests to use JarArchiveBuilder. Since we are not, we need to add source addition to the WebArchiveBuilder as well.

The repo still uses travis config which is now dead.
We should add GH actions as we did for CDI API repo.

Breaking up the sets of tests into separate categories, passivation based tests need to added to the CDI_FULL test group.

@starksm64 This change became incorrect after accepting the following change into cdi master - jakartaee/cdi#445

The test asserts that you can return a provider which return null for its getCDI() call, but the code now guards against it.
I will send a fix for this shortly.

The CDI TCK currently uses the Shrinkwrap API to construct its test applications, including dynamic generation of metadata files like beans.xml. This results in all of the beans.xml files in the TCK being stuck at version 1.1:

<beans xmlns="http://xmlns.jcp.org/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" bean-discovery-mode="all" version="1.1" xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd"/>

With the release of Jakarta EE 9 and the switch to the jakarta namespace, these should all be updated to version 3.0.

We need to distinguish between test common to both CDI-lite and the full CDI specification requirements. Discussions concluded that the best way to do this would be via a new cdi-full test group to mark tests that make use of features like @interceptors, @decorator, passiviation, portable extensions, etc.

I haven't found any mention of the default interceptor order in the spec but I saw multiple tests that are assuming some order:

org.jboss.cdi.tck.interceptors.tests.order.aroundConstruct.AroundConstructOrderTest
org.jboss.cdi.tck.interceptors.tests.contract.aroundConstruct.AroundConstructTest - testExceptions
org.jboss.cdi.tck.interceptors.tests.contract.aroundConstruct.bindings.AroundConstructTest - testExceptions

Should it be required to have all of the interceptors annotated with `@Dependent?

Going through some dep updates in Weld, I figured I cannot update TestNG from 6.x to 7.x because newer versions by default disable loading DTD from unsecure urls. And the files are declared in CDI TCK, namely here and here.

There are a few more tweaks needed in TCKs to update testng, such as custom listener extending a removed interface but I think master TCKs should be kept up to date instead of staying on an older version.

Issue is described in jakartaee/cdi#563
If we decide to accept the proposed solution, we'll need a simple TCK test that asserts this for standard class-based bean.

Build compatible extensions (in their @Enhancement and @Registration) phases state that their methods need to have exactly one parameter from certain types.

We should provide tests that break these restrictions (multiple or no params) and are expecting a deployment problem.

CDI 4.0 introduces build compatible extensions that will work under both, CDI Lite and Full.
We need to create tests for the functionality that will be akin to what we do for portable extensions.

Many tests do need to be updated for the empty beans.xml default behavior defined in:
jakartaee/cdi#500

Many beans need the @dependent annotation added to be seen.

This project refers to the Java EE JCP based TCK User Guide. Please consider contributing this to the Jakarta EE project so that it can be updated with the correct process details can be included (as well as updates related to Jakarta versions, etc.)