]
Cheng Fang commented on WFLY-12300:
-----------------------------------
What's the rules for generating javadocs in these forked api projects? For current
jboss batch api fork project, its pom inherits from jboss-parent so the javadocs rules are
specified in the parent and influenced by some configurable properties. So the javadoc
page footer will have:
Copyright © 2019 JBoss by Red Hat. All rights reserved.
Now it seems Jakarta api projects are required to have a link (license terms) pointing to
EFSL.html. For example,
© Copyright IBM Corp. 2014, 2019.
Use is subject to license terms.
So shall we use the upstream javadoc settings, and override the jboss-parent ones? I
think we didn't substantially modify the api to warrant our own copyright declaration,
and using the original one is more suitable.
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 JBoss specification API fork that existed in EAP 7.2, a designated owner for
that API jar has been determined. The task for each owner consists of:
# Create/update a
jboss.org Jakarta 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.
# For the fork, 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 (e.g. JPA), the component owner should plan to
file a PR moving to the Jakarta artifact (e.g.
jakarta.persistence:jakarta.persistence-api) as soon as the official version after Jakarta
is available in maven central (after Jakarta EE 8 final release).
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.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.management.j2ee:jakarta.management.j2ee-api|Jeff Mesnil|
|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.transaction:jakarta.transaction-api|Tom Jenkinson|
|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|