I started looking at this. Don't I need to update the wildfly-core repo dependencies and then wildfly repo? Just to update the CDI and related upstream dependencies of jakarta.activation, jakarta.annotation, jakarta.interceptor, jakarta.inject is going to be a massive change across both repos.On Tue, Apr 12, 2022 at 3:58 PM Brian Stansberry <brian.stansberry@redhat.com> wrote:On Tue, Apr 12, 2022 at 12:35 PM Scott Stark <sstark@redhat.com> 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-developersWe 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@redhat.com> 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@redhat.com> 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@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--Brian StansberryPrincipal Architect, Red Hat JBoss EAPHe/Him/His--Brian StansberryPrincipal Architect, Red Hat JBoss EAPHe/Him/His