Uploaded image for project: 'WildFly'
  1. WildFly
  2. WFLY-15098

Validate WildFly's use of Eclipse EE spec artifacts

XMLWordPrintable

    • Icon: Task Task
    • Resolution: Done
    • Icon: Blocker Blocker
    • 29.0.0.Final
    • None
    • Build System
    • 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.

              bstansbe@redhat.com Brian Stansberry
              bstansbe@redhat.com Brian Stansberry
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                Resolved: