On Wed, Feb 23, 2022 at 3:06 PM James Perkins <jperkins@redhat.com> wrote:

I think this makes sense and it's a good thing to get started on. We've already made the steps to require Java 11 so the next logical step to me is to start progressing with Jakarta EE 10.

I'm not sure this will happen, but what do we think of integrating say an Alpha release of a spec implementation that might not be fully implemented yet? What I'm thinking here is with RESTEasy the main branch is already on Jakarta REST 3.1 which targets Jakarta EE 10. We could potentially do an Alpha1 release which does not fully implement the new features, but would allow the TCK signature tests to pass. We would also have advanced knowledge of what we might be failing.

It's a bit of a tradeoff. It's certainly good to get impls in earlier so we can identify and sort issues. One way to look at it is for now we don't need main to always be releasable, but it should be understandable. And an important part of being understandable is interpreting test results, which somewhat includes the running and not regressing the TCK.

But part of working on any new EE release is a period where the TCK doesn't pass, so that's normal.

If bringing in a milestone release actually makes us more understandable, it seems good to me to do it even if it's not complete. E.g. a RESTEasy milestone that doesn't implement all new features, and thus fails TCK tests, is probably better than an older RESTEasy that doesn't implement any new features!

I'm a bit more picky about WF's own TS, as it presumably doesn't have any tests of the new features, so they shouldn't fail. :) So we need to be cautious about / quite reluctant to merge things that leave existing tests broken. Matej Novotny is doing a nice job of looking at that with https://github.com/wildfly/wildfly/pull/15254.

One catch is the spec itself is not released to Maven Central so an entry for the staging repository would be required:

I'm pretty reluctant to do that, as an artifact in a staging repo is not stable. If a staging repo is in our pom anyone who builds can be pulling GAVs into their local repo that may change later.  Hopefully specs will publish interim releases to maven central.  A number have.

<!-- Temporary repository for staged Jakarta EE 10 dependencies -->
<repository>
    <id>jakarta-staging</id>
    <name>Jakarta Staging</name>
    <url>https://jakarta.oss.sonatype.org/content/repositories/staging/</url>
    <layout>default</layout>
    <releases>
        <enabled>true</enabled>
        <updatePolicy>daily</updatePolicy>
    </releases>
    <snapshots>
        <enabled>false</enabled>
    </snapshots>
</repository>

Does this sound like something reasonable? I don't know if implementations, including RESTEasy, want to do a release that doesn't at least attempt to fully implement the spec but it seems worth considering.

Assuming the above seems reasonable, would we want a "pre-integration" JIRA or do we just want an implementation integration JIRA and component upgrade JIRA's after that?

Below I suggest a separate JIRA. for the interim work. Thereafter an upgrade sounds fine.

On Wed, Feb 23, 2022 at 12:46 PM Brian Stansberry <brian.stansberry@redhat.com> wrote:

I want to get things started re getting more fine-grained issues created for the various EE 10 spec migration issues linked to https://issues.redhat.com/browse/WFLY-15679. In many cases the issues directly linked to WFLY-15679 are too coarse-grained, because there are a number of distinct tasks that can be done separately for each, and to have a realistic sense of where we stand we need to have visibility into how things stand with those finer-grained pieces

A good recommendation I got from Tom Jenkinson is to add a comment on the various per-spec issues outlining the various types of detailed issues the assignee should consider filing, along with instructions as to how to do so.  The following is what I propose adding:

"Please consider creating subtasks of this issue for any of the following or other similar activities that can be accomplished as discrete pieces of work toward this JIRA's overall goal. Please add the 'EE10' label to any such issue.

* Ensuring that the standalone TCK for this spec can be run against a current build of WildFly Preview, and if possible reporting any issues to spec's working group before it is finalized.[1]
* Creating a branch for the EE 10 variant in the github repo for the JBoss fork of the spec, based on the appropriate code at Jakarta.[2]
* Integrating a milestone release of the spec API into WildFly's main branch.
* Integrating a milestone release of the implementation artifacts into WildFly's main branch.
* Integrating the final release of the spec API into WildFly's main branch.
* Integrating final releases of the implementation artifacts

Reminder: WildFly 27 is feature-boxed, so integrating non-final dependencies into main is not just ok, it is encouraged. Doing so lets us identify issues early.

We'll be using these finer-grained issues to better track progress on https://issues.redhat.com/secure/RapidBoard.jspa?rapidView=14333&view=planning.nodetail&issueLimit=100 and elsewhere."

Note that I don't include passing standalone or parts of the platform TCK here, because it's not clear to me that that kind of thing can be cleanly decomposed into discrete pieces of work. We know we need to pass the TCKs.

Note also that this message and the related issues are focused on WildFly Preview. Our ultimate goal is to convert the standard WildFly code to EE 10, ideally as soon as possible. But to do that we'll need to complete the work of getting native jakarta.* namespace variants of all our components. That work can proceed in parallel with our work on EE 10 if we continue to do it in WFP for now.


[1] I'd only add this to issues where a standalone TCK exists.
[2] I'd only add this to issues where we are using a fork of the EE 9.1 spec API code in WildFly Preview. 

Best regards,

Brian

_______________________________________________
wildfly-dev mailing list -- wildfly-dev@lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

--

James R. Perkins

JBoss by Red Hat

_______________________________________________
wildfly-dev mailing list -- wildfly-dev@lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

--

Brian Stansberry

Principal Architect, Red Hat JBoss EAP

He/Him/His

_______________________________________________
wildfly-dev mailing list -- wildfly-dev@lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s