10:49 a.m.
[
https://issues.jboss.org/browse/WFLY-12300?page=com.atlassian.jira.plugin...
]
Scott Marlow updated WFLY-12300:
--------------------------------
Description:
This is a top-level task for moving WildFly to specification API artifacts associated with
Jakarta EE 8.
The Jakarta EE 8 spec APIs are meant to be fully compatible with their Java EE 8
analogues, so this is not expected to result in runtime behavioral differences.
I don't anticipate code changes specific to this top level task. Instead changes will
be associated with other issues linked to this one.
The overall goal is to use API jars that either directly come from the Jakarta EE
projects, or that use code closely based on those projects; i.e. that are forks derived
from the Jakarta EE code that incorporate jboss.org specific changes and whose maintainers
monitor the Jakarta EE projects and bring over needed changes and contribute any relevant
jboss.org changes back.
For each specification API,that w a designated owner for that API jar has been determined.
The task for each owner consists of:
# Determining whether there is a need for a jboss.org fork.
# If there is a need for a fork, track work on that fork via issues in the
https://issues.jboss.org/projects/JBEE JIRA project. If there is a high-level issue for
that fork, the component owner *should* link it to this issue via a 'relates to'
link.
# Whether there is a need for a fork or the Jakarta EE project will be directly consumed,
the component owner *must* create a WFLY or WFCORE JIRA to track the change of the WildFly
code to use the Jarkarta EE based artifact. That can either be a subtask of this task, or
a separate issue linked to this once such that that issue is 'incorporated by'
this one. That JIRA should have priority 'Critical' and should have its Fix
Version set to 18.0.0.Final or 10.0.0.Final for WFCORE.
Generally, WildFly and WildFly Core do not accept non-Final artifacts into their master
branch. For projects that we are forking from the Jakarta EE projects, we are making an
exception to this rule:
_Once a Jakarta API project has made a staging release and submitted the specification for
formal approval, it is acceptable for the jboss.org fork of that project to produce a CR
release based on the code in that staged release and ask that it be incorporated into
master._
_In fact, doing this is strongly encouraged as it allows us to further verify the fork._
Once the staged release is approved, the component owner *must* as soon as possible (e.g.
the next working day) produce a .Final artifact from the fork and submit a component
upgrade PR.
For artifacts that will not involve a fork, the component owner should plan to file a PR
moving to the Jakarta artifact as soon as the official version is available in maven
central.
Following are the relevant APIs, organized by the maven GA of the artifact produced by the
Jakarta project, along with the 'owner' of that component:
||API||Owner||
|jakarta.annotation:jakarta.annotation-api|Yeray Borges|
|jakarta.batch:jakarta.batch-api|Cheng Fang|
|jakarta.ejb:jakarta.ejb-api|Cheng Fang/Tomasz Adamski|
|jakarta.el:jakarta.el-api|Scott Marlow|
|jakarta.enterprise:jakarta.enterprise.cdi-spec|Matej Novotny|
|jakarta.enterprise.concurrent:jakarta.enterprise.concurrent-api|Eduardo Martins|
|jakarta.faces:jakarta.faces-api|Farah Juma|
|jakarta.interceptor:jakarta.interceptor-api|Yeray Borges|
|jakarta.jms:jakarta.jms-api|Emmanuel Hugonnet|
|jakarta.json:jakarta.json-api|James Perkins|
|jakarta.json.bind:jakarta.json.bind-api|James Perkins|
|jakarta.management.j2ee:jakarta.management.j2ee-api|Jeff Mesnil|
|jakarta.persistence:jakarta.persistence-api|Scott Marlow|
|jakarta.resource:jakarta.resource-api|Stefano Maestri|
|jakarta.security.auth.message:jakarta.security.auth.message-api|Darran Lofthouse / Farah
Juma|
|jakarta.security.jacc:jakarta.security.jacc-api|Darran Lofthouse / Farah Juma|
|jakarta.servlet:jakarta.servlet-api|Flavia Rainone|
|jakarta.servlet.jsp:jakarta.servlet.jsp-api|Flavia Rainone|
|jakarta.servlet.jsp.jstl:jakarta.servlet.jsp.jstl-api|Flavia Rainone|
|jakarta.transaction:jakarta.transaction-api|Tom Jenkinson|
|jakarta.validation:jakarta.validation-api|Brian Stansberry|
|jakarta.websocket:jakarta.websocket-all|Flavia Rainone|
|jakarta.ws.rs:jakarta.ws.rs-api|Ron Sigal|
|jakarta.xml.bind:jakarta.xml.bind-api|Jim Ma|
|jakarta.xml.rpc:jakarta.xml.rpc-api|Jim Ma|
|jakarta.xml.soap:jakarta.xml.soap-api|Jim Ma|
|jakarta.xml.ws:jakarta.xml.ws-api|Jim Ma|
was:
This is a top-level task for moving WildFly to specification API artifacts associated with
Jakarta EE 8.
The Jakarta EE 8 spec APIs are meant to be fully compatible with their Java EE 8
analogues, so this is not expected to result in runtime behavioral differences.
I don't anticipate code changes specific to this top level task. Instead changes will
be associated with other issues linked to this one.
The overall goal is to use API jars that either directly come from the Jakarta EE
projects, or that use code closely based on those projects; i.e. that are forks derived
from the Jakarta EE code that incorporate jboss.org specific changes and whose maintainers
monitor the Jakarta EE projects and bring over needed changes and contribute any relevant
jboss.org changes back.
For each specification API, a designated owner for that API jar has been determined. The
task for each owner consists of:
# Determining whether there is a need for a jboss.org fork.
# If there is a need for a fork, track work on that fork via issues in the
https://issues.jboss.org/projects/JBEE JIRA project. If there is a high-level issue for
that fork, the component owner *should* link it to this issue via a 'relates to'
link.
# Whether there is a need for a fork or the Jakarta EE project will be directly consumed,
the component owner *must* create a WFLY or WFCORE JIRA to track the change of the WildFly
code to use the Jarkarta EE based artifact. That can either be a subtask of this task, or
a separate issue linked to this once such that that issue is 'incorporated by'
this one. That JIRA should have priority 'Critical' and should have its Fix
Version set to 18.0.0.Final or 10.0.0.Final for WFCORE.
Generally, WildFly and WildFly Core do not accept non-Final artifacts into their master
branch. For projects that we are forking from the Jakarta EE projects, we are making an
exception to this rule:
_Once a Jakarta API project has made a staging release and submitted the specification for
formal approval, it is acceptable for the jboss.org fork of that project to produce a CR
release based on the code in that staged release and ask that it be incorporated into
master._
_In fact, doing this is strongly encouraged as it allows us to further verify the fork._
Once the staged release is approved, the component owner *must* as soon as possible (e.g.
the next working day) produce a .Final artifact from the fork and submit a component
upgrade PR.
For artifacts that will not involve a fork, the component owner should plan to file a PR
moving to the Jakarta artifact as soon as the official version is available in maven
central.
Following are the relevant APIs, organized by the maven GA of the artifact produced by the
Jakarta project, along with the 'owner' of that component:
||API||Owner||
|jakarta.annotation:jakarta.annotation-api|Yeray Borges|
|jakarta.batch:jakarta.batch-api|Cheng Fang|
|jakarta.ejb:jakarta.ejb-api|Cheng Fang/Tomasz Adamski|
|jakarta.el:jakarta.el-api|Scott Marlow|
|jakarta.enterprise:jakarta.enterprise.cdi-spec|Matej Novotny|
|jakarta.enterprise.concurrent:jakarta.enterprise.concurrent-api|Eduardo Martins|
|jakarta.faces:jakarta.faces-api|Farah Juma|
|jakarta.interceptor:jakarta.interceptor-api|Yeray Borges|
|jakarta.jms:jakarta.jms-api|Emmanuel Hugonnet|
|jakarta.json:jakarta.json-api|James Perkins|
|jakarta.json.bind:jakarta.json.bind-api|James Perkins|
|jakarta.management.j2ee:jakarta.management.j2ee-api|Jeff Mesnil|
|jakarta.persistence:jakarta.persistence-api|Scott Marlow|
|jakarta.resource:jakarta.resource-api|Stefano Maestri|
|jakarta.security.auth.message:jakarta.security.auth.message-api|Darran Lofthouse / Farah
Juma|
|jakarta.security.jacc:jakarta.security.jacc-api|Darran Lofthouse / Farah Juma|
|jakarta.servlet:jakarta.servlet-api|Flavia Rainone|
|jakarta.servlet.jsp:jakarta.servlet.jsp-api|Flavia Rainone|
|jakarta.servlet.jsp.jstl:jakarta.servlet.jsp.jstl-api|Flavia Rainone|
|jakarta.transaction:jakarta.transaction-api|Tom Jenkinson|
|jakarta.validation:jakarta.validation-api|Brian Stansberry|
|jakarta.websocket:jakarta.websocket-all|Flavia Rainone|
|jakarta.ws.rs:jakarta.ws.rs-api|Ron Sigal|
|jakarta.xml.bind:jakarta.xml.bind-api|Jim Ma|
|jakarta.xml.rpc:jakarta.xml.rpc-api|Jim Ma|
|jakarta.xml.soap:jakarta.xml.soap-api|Jim Ma|
|jakarta.xml.ws:jakarta.xml.ws-api|Jim Ma|
Convert to Jakarta EE 8 specification APIs
------------------------------------------
Key: WFLY-12300
URL: https://issues.jboss.org/browse/WFLY-12300
Project: WildFly
Issue Type: Task
Components: Server
Reporter: Brian Stansberry
Assignee: Scott Marlow
Priority: Critical
Fix For: 18.0.0.Final
This is a top-level task for moving WildFly to specification API artifacts associated
with Jakarta EE 8.
The Jakarta EE 8 spec APIs are meant to be fully compatible with their Java EE 8
analogues, so this is not expected to result in runtime behavioral differences.
I don't anticipate code changes specific to this top level task. Instead changes will
be associated with other issues linked to this one.
The overall goal is to use API jars that either directly come from the Jakarta EE
projects, or that use code closely based on those projects; i.e. that are forks derived
from the Jakarta EE code that incorporate jboss.org specific changes and whose maintainers
monitor the Jakarta EE projects and bring over needed changes and contribute any relevant
jboss.org changes back.
For each specification API,that w a designated owner for that API jar has been
determined. The task for each owner consists of:
# Determining whether there is a need for a jboss.org fork.
# If there is a need for a fork, track work on that fork via issues in the
https://issues.jboss.org/projects/JBEE JIRA project. If there is a high-level issue for
that fork, the component owner *should* link it to this issue via a 'relates to'
link.
# Whether there is a need for a fork or the Jakarta EE project will be directly consumed,
the component owner *must* create a WFLY or WFCORE JIRA to track the change of the WildFly
code to use the Jarkarta EE based artifact. That can either be a subtask of this task, or
a separate issue linked to this once such that that issue is 'incorporated by'
this one. That JIRA should have priority 'Critical' and should have its Fix
Version set to 18.0.0.Final or 10.0.0.Final for WFCORE.
Generally, WildFly and WildFly Core do not accept non-Final artifacts into their master
branch. For projects that we are forking from the Jakarta EE projects, we are making an
exception to this rule:
_Once a Jakarta API project has made a staging release and submitted the specification
for formal approval, it is acceptable for the jboss.org fork of that project to produce a
CR release based on the code in that staged release and ask that it be incorporated into
master._
_In fact, doing this is strongly encouraged as it allows us to further verify the fork._
Once the staged release is approved, the component owner *must* as soon as possible (e.g.
the next working day) produce a .Final artifact from the fork and submit a component
upgrade PR.
For artifacts that will not involve a fork, the component owner should plan to file a PR
moving to the Jakarta artifact as soon as the official version is available in maven
central.
Following are the relevant APIs, organized by the maven GA of the artifact produced by
the Jakarta project, along with the 'owner' of that component:
||API||Owner||
|jakarta.annotation:jakarta.annotation-api|Yeray Borges|
|jakarta.batch:jakarta.batch-api|Cheng Fang|
|jakarta.ejb:jakarta.ejb-api|Cheng Fang/Tomasz Adamski|
|jakarta.el:jakarta.el-api|Scott Marlow|
|jakarta.enterprise:jakarta.enterprise.cdi-spec|Matej Novotny|
|jakarta.enterprise.concurrent:jakarta.enterprise.concurrent-api|Eduardo Martins|
|jakarta.faces:jakarta.faces-api|Farah Juma|
|jakarta.interceptor:jakarta.interceptor-api|Yeray Borges|
|jakarta.jms:jakarta.jms-api|Emmanuel Hugonnet|
|jakarta.json:jakarta.json-api|James Perkins|
|jakarta.json.bind:jakarta.json.bind-api|James Perkins|
|jakarta.management.j2ee:jakarta.management.j2ee-api|Jeff Mesnil|
|jakarta.persistence:jakarta.persistence-api|Scott Marlow|
|jakarta.resource:jakarta.resource-api|Stefano Maestri|
|jakarta.security.auth.message:jakarta.security.auth.message-api|Darran Lofthouse / Farah
Juma|
|jakarta.security.jacc:jakarta.security.jacc-api|Darran Lofthouse / Farah Juma|
|jakarta.servlet:jakarta.servlet-api|Flavia Rainone|
|jakarta.servlet.jsp:jakarta.servlet.jsp-api|Flavia Rainone|
|jakarta.servlet.jsp.jstl:jakarta.servlet.jsp.jstl-api|Flavia Rainone|
|jakarta.transaction:jakarta.transaction-api|Tom Jenkinson|
|jakarta.validation:jakarta.validation-api|Brian Stansberry|
|jakarta.websocket:jakarta.websocket-all|Flavia Rainone|
|jakarta.ws.rs:jakarta.ws.rs-api|Ron Sigal|
|jakarta.xml.bind:jakarta.xml.bind-api|Jim Ma|
|jakarta.xml.rpc:jakarta.xml.rpc-api|Jim Ma|
|jakarta.xml.soap:jakarta.xml.soap-api|Jim Ma|
|jakarta.xml.ws:jakarta.xml.ws-api|Jim Ma|
--
This message was sent by Atlassian Jira
(v7.12.1#712002)