[wildfly-dev] Re: Finer grained tracking of progress on EE 10

On Tue, Apr 12, 2022 at 12:35 PM Scott Stark <sstark(a)redhat.com&gt; wrote: > Ok, what is the zulip channel, and is it ok to just create PRs now? > Either https://wildfly.zulipchat.com/#narrow/stream/242838-Jakarta-EE or https://wildfly.zulipchat.com/#narrow/stream/174184-wildfly-developers > We probably need some ordering here as CDI and its dependencies being > updated will probably impact the most modules. > In WildFly Preview the CDI API is currently on 4.0.0-RC2 and Weld is 5.0.0.Beta1. BTW, our Mojarra fork already has a fix in place to deal with an incompatible change in CDI 4.1 -- https://github.com/jboss/mojarra/pull/92. We just haven't released an SP with that and integrated it. That's not sufficient for a proper EE 10 JSF impl, but it does correct the CDI 4 related JSF failures we were seeing in our own testsuite. > On Tue, Apr 12, 2022 at 11:44 AM Brian Stansberry < > brian.stansberry(a)redhat.com&gt; wrote: > >> Hi Scott, >> >> Sorry for the delay; I've been unexpectedly away for 2 weeks. >> >> Right now WF Preview in main is moving to using EE 10 APIs and impls. >> It's absolutely fine to make dependency updates in WFP to switch >> dependencies from EE 9.1. There'd probably need to be some discussion, as >> we're using a fork of Mojarra, but in general it's fine to move to EE 10 >> deps as they become available. >> >> Happy to chat here or in zulip about the mechanics of making dependency >> changes in WFP. Zulip is probably better. >> >> Before I left we were talking about moving standard WildFly in main off >> of javax.* namespace fairly soon so we could get rid of the large delta in >> main between std WF and WF Preview. That large delta worked ok for EE 9.1 >> dev but has become more of a hassle with EE 10 dev. We don't have all the >> needed jakarta.* components yet though, so this shift would mean we start >> doing transformation when building std WF as well. So this would not get >> rid of the transformation aspect. >> >> Chatting with Darran just now we were tentatively looking at making that >> switch in std WF next week. That's tentative though, as it hasn't been >> socialized at all beyond this post, plus I'm just catching up from being >> away and don't have an understanding of what's happened those two weeks and >> what needs to be done before we can make the switch. >> >> >> >> On Wed, Apr 6, 2022 at 12:04 PM Scott Stark <sstark(a)redhat.com&gt; wrote: >> >>> So is main/WildFly 27 targeting moving to these EE10 APIs and >>> implementations or is it still trying to use the transformation approach? >>> >>> I was looking at the CDI 4.0.0 TCK failures and one problem that needs >>> addressing is an update to JSF, which requires updates to Mojarra and Faces >>> in addition to the APIs. There are incompatible changes that cannot be >>> addressed via a simple transformation. I expect that the Faces related >>> changes will be one of the bigger ones and so I was trying to update the >>> related dependencies and realized the transformation approach was not going >>> to work. >>> >>> >>> On Wed, Feb 23, 2022 at 2:46 PM Brian Stansberry < >>> brian.stansberry(a)redhat.com&gt; 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... >>>> 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(a)lists.jboss.org >>>> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org >>>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s >>> >>> >> >> -- >> Brian Stansberry >> Principal Architect, Red Hat JBoss EAP >> He/Him/His >> > -- Brian Stansberry Principal Architect, Red Hat JBoss EAP He/Him/His