WDYT about doing in main what I did in the EE11 topic branch? https://github.com/wildfly/wildfly/commit/af6e723a27228884dbc3acdc66be10c... I did that in EE 11 because we know some EE 11 APIs or impls will require SE 17. So we need the SE 17 compiler to build with those deps. But we want our own (WFLY and WFCORE) code to remain SE 11 compatible. So the resulting binary level must be SE 11 and no language features or SE APIs > 11 can be used by our own code. Trying to only do this in the EE11 branch has proven to be a pain, because a bunch of things like github actions are using SE 11 to build and that blows up when run against the EE11 branch. If we did this I'd add a profile that could set the compiler version back to 11. CI jobs that need to both build the server and run the testsuite on 11 could activate that profile. Over the course of this year the SE 11 build and test use cases should become the secondary cases, ones that need special handling Iike activating a profile. SE 17 should become the 'default, it just works with no special effort' case. Supporting both EE 10 and 11 in different feature packs is one reason to keep SE 11 support around, but even with EE 10 our 'typical' case should become SE 17, not SE 11. Thoughts? -- 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...

I like the proposal! On Tue, Feb 27, 2024 at 11:48 PM Brian Stansberry < brian.stansberry(a)redhat.com&gt; wrote: > WDYT about doing in main what I did in the EE11 topic branch? > > > https://github.com/wildfly/wildfly/commit/af6e723a27228884dbc3acdc66be10c... > > I did that in EE 11 because we know some EE 11 APIs or impls will require > SE 17. So we need the SE 17 compiler to build with those deps. But we want > our own (WFLY and WFCORE) code to remain SE 11 compatible. So the resulting > binary level must be SE 11 and no language features or SE APIs > 11 can be > used by our own code. > > Trying to only do this in the EE11 branch has proven to be a pain, > because a bunch of things like github actions are using SE 11 to build and > that blows up when run against the EE11 branch. > > If we did this I'd add a profile that could set the compiler version back > to 11. CI jobs that need to both build the server and run the testsuite on > 11 could activate that profile. > > Over the course of this year the SE 11 build and test use cases should > become the secondary cases, ones that need special handling Iike activating > a profile. SE 17 should become the 'default, it just works with no special > effort' case. Supporting both EE 10 and 11 in different feature packs is > one reason to keep SE 11 support around, but even with EE 10 our 'typical' > case should become SE 17, not SE 11. > > Thoughts? > > -- > 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... >