4:55 a.m.
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
11 a.m.
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...
11:23 p.m.
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
2:08 a.m.
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
6:38 a.m.
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
6:44 a.m.
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
8:21 a.m.
FYI https://github.com/eclipse-ee4j/glassfish-concurro/pull/65 looks ready
for review of the initial ViewThread support. Looks like Ondra added
multi-release jar (Java SE 11 + 21).
On Mon, Jan 29, 2024 at 4: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
>
_______________________________________________
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...
8:45 a.m.
On Mon, Jan 29, 2024, 6:21 PM Scott Marlow <smarlow(a)redhat.com> wrote:
FYI https://github.com/eclipse-ee4j/glassfish-concurro/pull/65 looks
ready for review of the initial ViewThread support. Looks like Ondra added
multi-release jar (Java SE 11 + 21).
I meant virtual thread support.
On Mon, Jan 29, 2024 at 4: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
>>
> _______________________________________________
> 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...
>
9 a.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
3:21 a.m.
Do you want Jira issues for the commits (Maybe with an EE11 fix version for
now) in case we take the branch and merge it back to main?
On Fri, Jan 26, 2024 at 7:55 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...
6:30 a.m.
Yes, definitely.
On Mon, Jan 29, 2024 at 12:21 PM Darran Lofthouse <
darran.lofthouse(a)jboss.com> wrote:
Do you want Jira issues for the commits (Maybe with an EE11 fix
version
for now) in case we take the branch and merge it back to main?
On Fri, Jan 26, 2024 at 7:55 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
100
days inactive
104
days old
10 comments
5 participants
participants (5)
-
Brian Stansberry -
Darran Lofthouse -
Eduardo Martins -
Scott Marlow -
Scott Stark