FYI re the below. Delivery from the wildfly-dev list was disrupted for a
number of weeks so many subscribers likely were unaware of this thread.
On Fri, Jul 23, 2021 at 4:09 PM Brian Stansberry <
tl;dr; Let's figure out how to avoid duplicating module.xml
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.