6 p.m.
The issue, that Steve Millage from Payara had brought up in the thread
on the EE 11 plan review ballot to allow for Java SE 17, was that he
claimed the concurro project had already committed to producing a Java
SE 21 release, and having to support Java SE 17 would cost more time
than any potential disruption caused by Red Hat not producing
validation/CDI for Java SE 21 in the current timeframe.
If this a mute point because of the PR that already exists, I'll point that out.
On Mon, Jan 29, 2024 at 3:45 PM Eduardo Martins <emartins(a)redhat.com> wrote:
I think everyone except IBM uses Glassfish, at least that happened till EE10, so I guess
others will have same needs? If that’s not the case, if we need to change direction then
sure we could fork it, I know its code pretty well. IMHO what could be problematic would
be a shift to IBM impl, afaik it is quite different.
Anyway it feels I may be missing what is the main issue with what we have now? :-)
—E
On Mon, 29 Jan 2024 at 21:39, Brian Stansberry <brian.stansberry(a)redhat.com>
wrote:
>
> Eduardo, WDYT?
>
> I'm sure we'd have to shift more resources toward this spec than we
historically have. How that would be done I don't know right now. I'm sure the
devil's in the details; e.g. how big a delta would be required. Avoiding a fork by
helping upstream produce an MR artifact sounds better.
>
> On Mon, Jan 29, 2024 at 11:08 AM Scott Stark <sstark(a)redhat.com> wrote:
>>
>> W/hat if we had to create a fork that ran under Java SE 17 for passing
>> the EE 11 Concurrency TCK? This seems like one possible sticking point
>> to not getting the EE 11 plan review that supports SE 17 to pass.
>>
>> On Mon, Jan 29, 2024 at 8:23 AM Brian Stansberry
>> <brian.stansberry(a)redhat.com> wrote:
>> >
>> > org.glassfish:jakarta.enterprise.concurrent
>> >
>> > On Fri, Jan 26, 2024 at 8:00 PM Scott Stark <sstark(a)redhat.com>
wrote:
>> >>
>> >> What is our Jakarta Concurrency implementation?
>> >>
>> >> On Fri, Jan 26, 2024 at 1:56 PM Brian Stansberry
>> >> <brian.stansberry(a)redhat.com> wrote:
>> >> >
>> >> > I have pushed a new 'EE11' branch to wildfly/wildfly. This
can serve as a shared topic branch as we explore Jakarta EE 11 support for WildFly.
>> >> >
>> >> > I think anything we do with this branch at this point should be
restricted to WildFly Preview. Hopefully initial work can be limited to using different
component versions as EE 11 artifacts become available. There will be breaking changes in
EE 11 vs 10, but hopefully little or none that affects our integration code. At this
stage these do not need to be Final/GA artifacts.
>> >> >
>> >> > At this point the only difference between the EE11 and main
branches is one commit to require use of SE 17+ to build, while still requiring SE 11 as
the source/target/release version. We'll need to compile against SE 17 dependencies,
but at this point there's not a strong need for our own code to move beyond SE 11, and
staying there gives us the greatest flexibility. For more see
https://issues.redhat.com/browse/WFLY-18967.
>> >> >
>> >> > Best regards,
>> >> >
>> >> > --
>> >> > Brian Stansberry
>> >> > Principal Architect, Red Hat JBoss EAP
>> >> > WildFly Project Lead
>> >> > He/Him/His
>> >> > _______________________________________________
>> >> > wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org
>> >> > To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org
>> >> > Privacy Statement: https://www.redhat.com/en/about/privacy-policy
>> >> > List Archives:
https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message...
>> >>
>> >
>> >
>> > --
>> > Brian Stansberry
>> > Principal Architect, Red Hat JBoss EAP
>> > WildFly Project Lead
>> > He/Him/His
>>
>
>
> --
> Brian Stansberry
> Principal Architect, Red Hat JBoss EAP
> WildFly Project Lead
> He/Him/His