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
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.
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@redhat.com> wrote:
>
> org.glassfish:jakarta.enterprise.concurrent
>
> On Fri, Jan 26, 2024 at 8:00 PM Scott Stark <sstark@redhat.com> wrote:
>>
>> What is our Jakarta Concurrency implementation?
>>
>> On Fri, Jan 26, 2024 at 1:56 PM Brian Stansberry
>> <brian.stansberry@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@lists.jboss.org
>> > To unsubscribe send an email to wildfly-dev-leave@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/GSNS2EBGMZVAYHDNRSABASMOVG4IOQEE/
>>
>
>
> --
> 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
wildfly-dev mailing list -- wildfly-dev@lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave@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/O7W7IZG27CU5SF2FHDGE2GDUSFV7BJCJ/