[wildfly-dev] Re: WildFly Preview and module.xml files

tl;dr; Let's figure out how to avoid duplicating module.xml files in the WildFly Preview code. Long version 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: https://github.com/wildfly/wildfly/pull/14507 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. WDYT? * 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. Best regards, Brian