I’m currently reviewing the proposal  of WFLY-14934  feature request
and I’m struggling to understand what are the objectives of this feature.
The “Relevant Installation Types” section with selected “OpenShift s2i” in
the proposal  suggest this feature is OpenShift focused. However the
only differences between this new feature and existing bootable JAR can be
observed on bare metal. On bare metal this feature brings the same features
as bootable JAR does but it adds three things: persistent configuration,
multiple deployments and direct access to each file of the provisioned
server. In S2I scenarios there seems to be no difference between bootable
JAR and this feature. Form of the server in the application image is as far
as I know transparent for the user.
What are the real use-case scenarios of this feature?
 https://issues.redhat.com/browse/WFLY-14934 and
Jan (Honza) Kasik
Quality Engineer, EAP QE
tl;dr; Let's figure out how to avoid duplicating module.xml files
in the WildFly Preview code.
One of the things we're trying to do with WildFly Preview is to make the
code differences vs standard WildFly as minimal as possible. There are some
things that have to differ, like some Galleon feature-group or layer
definitions (because WFP has different standard config files), plus the pom
dependency stuff because WFP uses some native EE 9.1 artifacts. But beyond
that the less code the better, particularly any duplicated code.
One area where we've been creating a lot of duplicated code is various
module.xml files. You don't need to fork a module.xml into the
ee-9/feature-pack src tree if all you want to do is use a different version
of an artifact. But for any other change, we've been forking. That's
increasingly problematic as any forked module.xml is a bug waiting to
happen. And we're starting to get more of them.
Most, probably all, module.xml forks are because the WFP module uses an
artifact with a different GAV or maven classifier. The dependency set is
the same.* So how can we avoid forking the module.xml?
One possibility is to use maven-resource-plugin filtering to control the
module.xml artifact name attribute. This is actually pretty
straightforward -- a POC is here:
I wouldn't want to get too carried away with that, e.g. replacing totally
different GAVs. But for things where a project is releasing javax and
jakarta artifacts at the same time with slightly different artifact ids or
using a qualifier, it seems reasonable.
* Note that there is no need at this point to fork a module.xml because it
has a dependency on some javax.xxx.api module (for the EE API) and you want
to change it to jakarta.*. In WFP we provide javax.xxx.api modules but
they are all aliases to the corresponding jakarta.xxx.api module. This
means a module.xml with an EE API dep will work unchanged. Others may
disagree, but I think at this stage it's best to use the javax.* modules
for all deps, even in WFP. It just seems cleaner to do things one way vs
having a mix. But I totally admit that's a personal preference.
We've done a lot of good work on WildFly Preview in the last year but as
planning work in Jakarta on EE 10 starts to get underway I hope we can make
a lot more progress, specifically in increasing the number of 'native'
jakarta.* EE 9.1 components' we use. This will allow us to focus on EE 10
dev when the time comes. Ideally by the time WF 26 comes out in the Dec/Jan
timeframe we'll have eliminated the transformation of artifacts that we do
when provisioning a server with the wildfly-preview feature pack, and
instead we'll be using native jakarta artifacts available in maven central
This thread is meant to drive discussion about how to do this. WF devs of
course don't control many projects that provide components, so for those
this discussion would be more informational for the WF subsystem leads who
interact with those communities.
By a 'native jakarta component' I mean one whose compiled artifacts use the
jakarta namespace and otherwise support EE 9.1.
If at all possible it should also provide a matching -sources jar, to help
provide a better debugging experience. This is particularly important for
components against which WildFly users would compile applications.
For artifacts we package in modules that we don't mark with
jboss-api="private" or jboss-api="unsupported", it should also provide a
matching -javadoc jar.
More urgent are components against which other WF components compile, where
EE classes are part of the API compiled against. The closer a component is
to the root of a dependency chain, the higher the priority, as having a
native component makes it easier for other components to do their work.
EE API spec forks are not necessarily urgent unless WF itself intends to
use that fork instead of the Eclipse project. (We need to formally resolve
which EE 9+ spec forks WF needs, which is a separate topic. WF Preview is
currently using fewer spec forks than standard WF.)
There are a number of approaches a project can follow to produce native
components, each with pros and cons
1) Branching and updating code.
This obviously works, but it comes with a big cost if there will be
continued demand for updates using the javax.* namespace. IMHO it is pretty
likely that there will be continued demand for many components to provide
updates to their javax.* releases.
I had been thinking that during the WF 26 cycle WF itself might follow this
approach, but I'm increasingly thinking we should follow one of the other
An issue with this is it means you are compiling, which means you need
jakarta.* components to compile against, which may not be available. If
not you can try Stuart Douglas's optimus project to generate during your
build transformed deps to build against. James Perkins tells me he is
working on something along these lines to add to wildfy-extras/batavia.
Some components might be able to support both javax and jakarta in the same
code base abstracting away the EE API and providing adapters. Not much to
say about this; you know better if it fits your component.
3) Bytecode transformation with a maven qualifier
Here you update your pom and add a plugin execution that transforms that
maven module's normal javax binary to produce another artifact with a
The key downside to this is it doesn't produce matching -sources.jar or
-javadoc.jar artifacts. So I don't think it should be our preferred
Jackson 2.12 did this for a few artifacts, e.g.
They used the shade plugin. This can also be done using
wildfly-extras/batavia or Eclipse Transfomer directly.
4) New maven module, transform all artifacts
Create a new maven module to pair with your javax-based module. Add
"-jakarta" to the artifactId. Module just has a pom. Pom uses plugins that
call the Eclipse Transformer to transform *all* the artifacts from module
it is paired with (binary jar, -sources.jar, -javadoc.jar)
Narayana did this -- see https://github.com/jbosstm/narayana/pull/1824/files
Hibernate does this for its 5.5 series. This is a gradle build.
5) New maven module, transform source and build
Create a new maven module to pair with your javax-based module. Add
"-jakarta" to the artifactId. Module just has a pom. Use the Eclipse
Transformer to transform the unzipped source from the javax module, writing
it to generated-sources in the jakarta.* module. Then build the jakarta.*
artifacts from the generated source.
Examples of this:
A pro (and con) of this approach is you can also transform src/test and
then run the tests. (A con because it can send you down rabbit holes
getting tests to work. That can reveal things that are good to know though.)
Another con is again this means you are *compiling* which means you may
need jakarta.* deps to compile against.
6) Don't transform
There may be some components that use EE APIs internally but objects don't
leak in or out. A possible example would be JSON where a component might
want to deal with JSON for completely internal purposes, and used EE JSON
for convenience. In theory WF could provide javax JSON via internal modules
and the components using it could skip transformation.
I did a similar thing with H2, which provides some servlet integration
classes that WF does not support. I see no reason to worry about a native
jakarta.servlet H2 so I sent up a PR to disable transformation of it:
Lots to digest here; discussion is very much welcome.