-
Task
-
Resolution: Done
-
Blocker
-
None
-
Undefined
Standard WildFly and WildFly Preview differ in the source of many of the EE spec API artifacts they use, with Preview using a number of artifacts from Eclipse while standard WF is using JBoss forks.
The reason for this is that in a perfect world using the Eclipse artifacts and not maintaining a long term fork is preferable, so when I started Preview I used the Eclipse artifacts unless they showed failures in the tests we ran of Preview, both the integration testsuite and the EE 9[.1] TCK. I didn't have the time to evaluate all the spec artifacts or coordinate an evaluation and preferred to see how we far we could get with the Eclipse ones.
Note that the integration testsuite coverage of WF Preview is considerably less extensive than the coverage of standard WildFly, so it's possible tests we're not running with Preview would reveal issues. Besides TCK, WF Preview currently basically consists of these two jobs:
https://ci.wildfly.org/viewType.html?buildTypeId=WF_Ee9BootableJarLinuxJdk8
https://ci.wildfly.org/viewType.html?buildTypeId=WF_WildFlyPreviewLinuxJdk11
Before EE > 8 support in WF moves beyond the preview stage, we need to formally validate that the Eclipse artifacts are acceptable alternatives to the JBoss spec forks. This task consists of evaluating the differences between the existing spec forks and the Jakarta EE 8 spec projects on which they are based, and deciding whether there are differences that must be retained.
Note that simple bug fixes in the forks that are appropriate for the Eclipse spec projects should be proposed as patches to the Eclipse projects, in time for them to be incorporated in the EE 10 API releases.
There has been formal and informal evaluation of this general topic in the past, so hopefully in most cases all that's needed is simply ratifying that using the Eclipse artifact is fine. For cases where we clearly need to maintain a fork, the task will be to produce such a fork based on the EE 9.1 APIs.
I will file separate issues for each relevant API. Please use those for relevant commit messages etc, not this issue.
If sticking with the Eclipse artifact is fine for a particular spec, please resolve the relevant JIRA as Done with a comment to that effect.
- incorporates
-
WFLY-15099 Validate WildFly Preview's use of the Eclipse jakarta.interceptor spec artifact
- Resolved
-
WFLY-15100 Validate WildFly Preview's use of the Eclipse jakarta.authentication spec artifact
- Resolved
-
WFLY-15101 Validate WildFly Preview's use of the Eclipse jakarta.authorization spec artifact
- Resolved
-
WFLY-15102 Validate WildFly Preview's use of the Eclipse jakarta.annotation spec artifact
- Resolved
-
WFLY-15104 Validate WildFly Preview's use of the Eclipse jakarta.servlet spec artifact
- Resolved
-
WFLY-15105 Validate WildFly Preview's use of the Eclipse jakarta.servlet.jsp spec artifact
- Resolved
-
WFLY-15106 Validate WildFly Preview's use of the Eclipse jakarta.websocket spec artifact
- Resolved
-
WFLY-15107 Validate WildFly Preview's use of the Eclipse jakarta.enterprise.concurrent spec artifact
- Resolved
-
WFLY-15109 Validate WildFly Preview's use of the Eclipse jakarta.batch spec artifact
- Resolved
-
WFLY-15110 Validate WildFly Preview's use of the Eclipse jakarta.ejb spec artifact
- Resolved
-
WFLY-15111 Validate WildFly Preview's use of the Eclipse jakarta.jms spec artifact
- Resolved
-
WFLY-15112 Validate WildFly's use of the Eclipse jakarta.resource spec artifact
- Closed
-
WFLY-15103 Validate WildFly Preview's use of the Eclipse jakarta.faces spec artifact
- Closed
-
WFLY-15108 Validate WildFly Preview's use of the Eclipse jakarta.transaction spec artifact
- Closed