On 12/2/24 1:06 PM, Brian Stansberry wrote:
I'm curious what impact it would have on people if the build and
dist
modules were moved under galleon-pack and the ee-build and ee-dist
modules were moved under ee-galleon-pack.
For Jakarta EE TCK testing we build WildFly and then change into the
dist/target folder and then archive the build via shell commands that
look like:
cd dist/target
rm -f *.zip *.jar *.gz wildfly-galleon-*.txt
zip -r wildfly.zip wildfly*
The reason for the file removal is to ensure the zip operation does not
see other files named "wildfly.*something".
Internal to the WF build any other modules that look for those
locations should be relying on a maven property, so in theory it could
be easy to tweak that property. But there might be a problem with
other automation external to the build (e.g. github actions) that make
assumptions about the location of those modules.
We typically just change our TCK testing script to adjust to whatever
changes are made to how we build WildFly. I'm only mentioning these TCK
details in case it helps with this discussion. I don't expect that the
WildFly build needs to worry about how TCK testing builds WildFly.
I'm asking this as part of some brainstorming about how to organize
the code base to better reflect the different variants of WF we
produce. Currently the build and dist for WFP are located under the
same dir 'preview' as the bits that produce the WFP feature pack and
channel. Unlike the various modules that produce java artifacts (e.g.
subsystems), the dist modules are tightly bound to the FP that
produces them, so grouping them makes some sense.
NBD; I'm just brainstorming.
--
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 towildfly-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.or...