WildFly Releases in 2022
by Brian Stansberry
Hi WildFly developers,
Over the course of 2021 we've been working hard on WildFly, both on
improving our EE 8 server and on using WildFly Preview to get ready for the
transition to EE 10. A question throughout has been when's the right to
shift our primary development efforts toward the EE 10 server.
There have been a number of conversations about this over the last couple
months, and it seems clear that now is the time to do this. Producing a
time-boxed WildFly 27 in March that is both EE 8 (standard WF) and EE 9+
(WF Preview) is not an effective use of our resources; we'll just end up
being slow on EE 10 while not really being able to deliver all that many
non-EE 10 related features.
So, instead we're going to target WildFly 27 at EE 10 support in standard
WildFly. 27 won't be a quarterly time-boxed release; instead it will be
feature boxed, done when we are satisfied with its feature set (primarily
EE 10).
I wrote a post with more about this at
https://www.wildfly.org/news/2022/01/21/WildFly-2022/
I've also started a forum thread for discussions with the WildFly user
community:
https://groups.google.com/g/wildfly/c/APYM_GvaHLs
My thought was to use this thread / this list for discussions about the
actual development strategy. And of course Zulip is a good place to chat.
We will be producing a 26.1 in March. The 26.x branch that we used for
today's WildFly 26.0.1 will be used for that. That means any features or
fixes for 26.1 will need to be applied to main first and then ported to
26.x. (For WildFly Core, it's the 18.x branch that will be used for WildFly
26.1.)
I don't expect anyone to port all features and fixes to 26.x; our focus
IMHO should be on main. But 26.1 is a good way to get community bake for
new features, and providing bug fixes to our users is always a good thing.
In particular we should work to bring in component upgrades that resolve
CVEs.
26.1 will be an EE 8 release (9.1+ in Preview) that can run on SE 8. It
will be the last such feature release.
Because WF 27 is now feature-boxed we can adjust some of the development
practices that we've used in WildFly since we started doing the quarterly
time-boxed releases. For example, it is permissible to use non-Final
component releases in main, although this should be limited to cases where
it's necessary for EE 10 work. I'm sure as this work goes along there will
be disruptions in our ability to run / pass TCKs. The main branch must
always be able to compile/build and the testsuites should pass. If there
are situations where particular tests won't be able to function for a
period we can discuss disabling them, but any such disabling of tests
should be accompanied by a priority Blocker JIRA to get them working again.
A key task is the ongoing effort to get native jakarta.* variants of all of
our components.
I think in the next week or so we should look hard into changing the build
to SE 11 and dropping SE 8 builds and testing. We should also drive to
eliminate any barrier to compiling with SE 17, so we can more easily add SE
17 CI jobs. Basically I'd like to replace all the current SE 8 CI jobs with
SE 11 ones, and then replace the current SE 11 jobs with SE 17. I think
it's good to get this shift out of the way early so we're not dealing with
it as we start bringing in EE 10 impls and moving the code away from
javax.*.
Best regards,
--
Brian Stansberry
WildFly Project Lead
He/Him/His
4 years
Fwd: Creating -jakarta variants of WildFly artifacts using source transformation
by Yeray Borges Santana
I mistakenly send this to wildfly google groups some time ago, but it
should have been sent to the WildFly Dev mailing list.
---------- Forwarded message ---------
From: Yeray Borges Santana <yborgess(a)redhat.com>
Date: Fri, Dec 17, 2021 at 11:00 AM
Subject: Re: [wildfly-dev] Creating -jakarta variants of WildFly artifacts
using source transformation
To: WildFly <wildfly(a)googlegroups.com>
Hello everyone,
We have recently reorganized the different pieces that build the
wildfly-preview Galleon Pack [1]; the motivation of this change is to be
able to selectively pick up whatever we need to build other Galleon
Packs. We have now different modules for Jakarta artifacts and galleon
content related to Microprofile and non MicroProfile stuff, and a new
module to hold all the Jakarta EE 9 API.
This new code structure changes a bit two steps of Brian's tutorial. Please
follow up with them if you have a related PR in progress or are going to
create a new one soon, thanks.
[1] https://github.com/wildfly/wildfly/pull/14968
On Wed, Oct 20, 2021 at 10:05 PM Brian Stansberry <
brian.stansberry(a)redhat.com> wrote:
> Last July, I started a thread[1] here about ways to get native jakarta
> namespace variants of artifacts, which we need for our move to EE 10. One
> of the items discussed there was "5) New maven module, transform source
> and build". I'm posting here as a kind of status update and tutorial about
> that approach.
>
> At this point there are 11 maven modules in the WildFly main source
> tree[2] that are producing artifacts using the approach described there,
> and there are PRs open for at least a couple more. I have filed or soon
> will file JIRAs[3] for all the remaining WF main tree's modules that
> produce artifacts that WildFly Preview currently is transforming when it
> provisions a server[4], so there will be more coming.
>
> Overview
>
> The high level overview of how these work is that a pom-only maven module
> is created that corresponds to an existing module that produces an javax
> artifact. The new module's pom uses the batavia maven plugin[5] (and
> Eclipse Transformer under the covers) to find the source code from the
> existing maven module, transform it, and write the transformed output to
> the target/ dir of the new module, specifically in the
> 'generated-resources', 'generated-sources', 'generated-test-resources' and
> 'generated-test-sources' dirs. That generated source is then associated
> with the overall maven execution for the module, and thereafter gets
> included as part of the subsequent compile, test, package, install and
> deploy goals executed for the module. So, presto we have native jakarta
> source available that is then compiled and tested and used to
> package/install/deploy binary, source and javadoc jars.[6]
>
> The generated source does not get committed into the git repository. The
> git repo only has the pom.
>
> It's a common thing for generated source to be used in an artifact build;
> for example it's the technique we use to generate implementation classes
> from the XXXLogger interfaces we have for each of our subsystems. What
> we're doing here just takes this concept to the max by generating 100% of
> the source, including test source.
>
> Tutorial
>
> I'm going to use a PR I sent up yesterday to illustrate how to create one
> of these:
>
> https://github.com/wildfly/wildfly/pull/14822
>
> Steps:
>
> 1) Decide whether the module you want to work on is ready. If you're not
> the component lead responsible for the module, ask that lead. To see if a
> module is 'ready', look at its compile time dependencies and see if it
> still depends on other artifacts for which a native jakarta variant is
> needed and doesn't exist yet. Ask here or in zulip if you are not sure!
> Things can change quickly, and there also may be some edge cases where
> you'd think you need a jakarta namespace dependency but you really don't.
>
> If there are dependencies that are not ready yet, stop and wait until they
> are available. Or be prepared for your new module to not build, at which
> point you can save your work and wait.
>
> 2) Create a new dir under ee-9/source-transform for your new module. If
> the module you are transforming isn't directly under the root of the WF
> source, then create a matching structure under ee-9/source-transform. For
> example, I created ee-9/source-transform/jpa/spi to produce a jakarta.*
> variant of jpa/spi.
>
> 3) Copy the pom.xml from an *existing source-transform module* into your
> new dir. Easiest is to use one that comes from a dir the same # of levels
> below source-transform as your new dir, so a couple relative paths in your
> new pom are correct. For my PR I copied over
>
>
> https://github.com/wildfly/wildfly/blob/main/ee-9/source-transform/weld/c...
>
> Don't start with the pom from your source input module. Unless you want to
> work out how to adapt it to use the source transformation. :) Granted it's
> not rocket science. But it's easier for code reviewers to look at these if
> they look like the other ones.
>
> 4) Change the artifactId in your new pom to *exactly* match the artifactId
> of the module you're transforming, but with "-jakarta" appended:
>
>
> https://github.com/wildfly/wildfly/pull/14822/files#diff-d9ae5e5e0388bc9e...
>
> 5) Change the 'name' tag to something appropriate, like
>
>
> https://github.com/wildfly/wildfly/pull/14822/files#diff-d9ae5e5e0388bc9e...
>
> 6) Change the 'transformer-input-dir' maven property to point to the root
> of the module you are transforming:
>
>
> https://github.com/wildfly/wildfly/pull/14822/files#diff-d9ae5e5e0388bc9e...
>
> This property is used in the batavia maven plugin config in the parent
> source-transform dir. Each child module sets the property to point to the
> correct input source for that module.
>
> This one small tweak is the only thing you need to deal with to get the
> source transformation set up.
>
> 7) Configure dependencies.
>
> a) Delete the existing 'dependency' entries in your new pom, as they are
> for whatever random file you copied in.
>
> b) Copy over the 'dependency' entries from the pom of the module you are
> transforming.
>
> c) For any entries where your new artifact uses a dependency with a
> different groupId:artifactId from the one you're transforming, change the
> GA. For example:
>
> EE 8 JTA
>
> https://github.com/wildfly/wildfly/blob/25.0.0.Final/jpa/spi/pom.xml#L58
>
> became EE 9.1 JTA
>
>
> https://github.com/wildfly/wildfly/pull/14822/files#diff-d9ae5e5e0388bc9e...
>
> Or, in another example
>
> an EE 8 based 'ee' subsystem module dep:
>
>
> https://github.com/wildfly/wildfly/blob/25.0.0.Final/ee-security/pom.xml#L45
>
> became instead a dep on the new '-jakarta' variant:
>
>
> https://github.com/wildfly/wildfly/pull/14652/files#diff-7ed0e6e85369889b...
>
> d) A nice to have is to separate from the others in the dependency listing
> deps where WF Preview is using a different artifact from what standard WF
> is using. For example see
>
>
> https://github.com/wildfly/wildfly/pull/14822/files#diff-d9ae5e5e0388bc9e...
>
> This separation helps code reviewers.
>
> 8) Tell your new module's parent to include it in the build:
>
>
> https://github.com/wildfly/wildfly/pull/14822/files#diff-37dfe0d6acd41e18...
>
> 9) The ee-9/pom.xml maintains a dependencyManagement set for all artifacts
> that differ in WF Preview from what is in standard WF. These can either be
> artifacts whose GA is not used at all in standard WF, or ones where WF
> Preview uses a different version. Add your new artifact to this
> dependencyManagement:
>
>
> https://github.com/wildfly/wildfly/pull/14822/files#diff-5ddee375313bf441...
>
> 10) Allow re-use of the module.xml that incorporates this artifact between
> standard WF and WF Preview. This is done by modifying the module.xml to add
> an expression that the maven-resource-plugin replaces when preparing the
> module.xml resource file for use in the FP build:
>
>
> https://github.com/wildfly/wildfly/pull/14822/files#diff-f89017fad51e240c...
>
> The added @module.jakarta.suffix@ gets replaced either with an empty
> string (standard WF) or "-jakarta" (WF Preview)
>
> 11) Add your new artifact as a dependency of ee-9/feature-pack/pom.xml.
> This is needed so the wildfly-preview Galleon feature pack can utilize your
> new artifact:
>
>
> https://github.com/wildfly/wildfly/pull/14822/files#diff-1375aa050fa94d63...
>
We are no longer adding artifacts to ee-9/feature-pack/pom.xml. Your new
artifact should be now placed under:
11.a) ee-9/common-microprofile; if your artifact is a MicroProfile related
artifact
https://github.com/wildfly/wildfly/blob/fb01a18b2836eabbda15ed6759c361ca3...
11.b) Otherwise, place it under ee-9/common
https://github.com/wildfly/wildfly/blob/fb01a18b2836eabbda15ed6759c361ca3...
Notice that these artifacts, together with the ee-9 API ones, are now
pulled in into ee-9/feature-pack:.
https://github.com/wildfly/wildfly/blob/984717592792f3936383f5d3266df9f20...
>
> 12) Tell the wildfly-preview feature-pack build to ignore the no-longer
> relevant javax artifact you're replacing. This saves build time, compute
> resources and false positives in the build log that make us think your
> artifact hasn't been handled yet.
>
>
> https://github.com/wildfly/wildfly/pull/14822/files#diff-1375aa050fa94d63...
>
> (Note the precise spot to put that 'exclude' may differ, a bit. Ask if
> this is unclear.)
>
> 13) Add an entry for your new artifact in the license.xml file for the
> wildfly-preview feature back. Put it in the right alphabetical spot based
> on its groupId and artifactId.
>
>
> https://github.com/wildfly/wildfly/pull/14822/files#diff-11ae0f2f274afa8c...
>
Similar to the artifacts change, the license file is now split in
MicroProfile and non Microprofile related:
13.a)
ee-9/common-microprofile/src/main/resources/license/preview-feature-pack-common-microprofile-licenses.xml
13.b)
ee-9/common/src/main/resources/license/preview-feature-pack-common-licenses.xml
>
> 14) Do a build and if good, commit and send up a PR! If your input module
> had tests, your new module should as well and they should run. If you're
> curious, have a look in the new target/generated-xxx dirs to see the
> source..
>
> This sounds like a lot, and I suppose it is, but other than step 7) it's
> all very simple stuff, mostly things you'd do any time you add a new module
> to the WF source tree. Granted I'm practiced at this, but it took me about
> half an hour to work up the PR I've been using as an example.
>
> If you're interested in doing one of these, and the component lead
> responsible for the input module is agreeable, please go for it and feel
> free to ask for help.
>
> [1]
> https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/thread/...
>
> [2] Child modules under
> https://github.com/wildfly/wildfly/tree/main/ee-9/source-transform
>
> [3] High level tracker issues for this work are
> https://issues.redhat.com/browse/WFLY-15436 and
> https://issues.redhat.com/browse/WFLY-15437. I'm filing separate issues
> for individual pieces and am linking those to one or the other of these two
> trackers.
>
> [4]
> https://docs.google.com/spreadsheets/d/1TekfyRb2UBCLqsPQ83WTg8XOw9qwuHVSh...
> shows all artifacts (not just those from the WF source tree) that the
> WildFly Galleon plugin was transforming in builds on Oct 14. The rows that
> end with '-26.0.0.Beta1-SNAPSHOT.jar' are ones that are produced by
> WildFly main itself. I add new tabs to that document weekly to track
> progress on reducing the # of artifacts being transformed by the Galleon
> plugin.
>
> [5]
> https://github.com/wildfly/wildfly/blob/main/ee-9/source-transform/pom.xm...
>
> [6]
> https://repository.jboss.org/org/wildfly/wildfly-mail-jakarta/25.0.0.Final/
> which was produced from a maven module with nothing in it but a pom.
>
> Best regards,
>
> --
> Brian Stansberry
> Project Lead, WildFly
> 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
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
4 years
jakarta variant of the WildFly transactions subsystem
by Michael Musgrove
I am making some changes to support a native jakarta variant of the WildFly transactions subsystem.
I followed Brian's instructions (https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/thread/...) but I get the following error building the "WildFly: EE 9 Preview Galleon Feature Pack" module:
> Forked embedded process has failed with the following error:
> java.lang.IllegalStateException: WFLYEMB0022: Cannot invoke 'start' on embedded process
> java.lang.Exception: WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details. - Server configuration file in use: standalone.xml
Can anyone give me some pointers on how to debug this issue?
4 years
