[jboss-jira] [JBoss JIRA] (WFLY-12914) Upgrade Galleon to 4.2.1.Final and the wildfly-galleon-plugins to 4.2.2.Final

Upgrade Galleon to 4.2.1.Final and the wildfly-galleon-plugins to 4.2.2.Final ----------------------------------------------------------------------------- Key: WFLY-12914 URL: https://issues.redhat.com/browse/WFLY-12914 Project: WildFly Issue Type: Component Upgrade Components: Build System Reporter: Brian Stansberry Assignee: Brian Stansberry Priority: Major Fix For: 19.0.0.Beta1 Upgrade Galleon to match the versions used in core. The current versions should allow trimming quite a bit of boilerplate from all the places where we provision servers: Alexey Loubyansky 5:07 PM I did a bit more work on this, fixed a couple of issues and just released Galleon 4.2.1.Final and WFGP 4.2.1.Final Alexey Loubyansky 5:07 PM also opened a PR to upgrade WildFly Core to these releases https://github.com/wildfly/wildfly-core/pull/4025 5:08 PM upgrading doesn't affect anything, except the bug fixes contained in those versions 5:10 PM however, for wildfly, i think we should use GAVs as feature-pack locations for feature-pack dependencies, in place of Galleon FPL 5:11 PM the benefit would be to avoid the universe resolver in maven builds 5:11 PM and also a simplified (mojo) provisioning config Brian Stansberry 5:14 PM good timing; I'm working on how to add a new f-p to wildfly (for microprofile stuff) so i should use best practices :) Alexey Loubyansky 5:16 PM by simplified provisioning config i mean that the selected block should be removed completely https://github.com/wildfly/wildfly/blob/master/build/pom.xml#L84-L97 5:16 PM the only reason it is there is to avoid resolution from the universe 5:17 PM with GAVs for dependencies, it won't be necessary anymore Brian Stansberry 5:17 PM what about <inheritConfigs>false</inheritConfigs> ? Alexey Loubyansky 5:18 PM that was there to workaround a bug which was fixed in 4.2.0.Final Brian Stansberry 5:18 PM how about 5:18 PM <included-packages> <name>docs.examples.configs</name> </included-packages> 5:19 PM assuming that's not in the top level f-p Alexey Loubyansky 5:19 PM that should definitely stay, it's not in the selected block 5:19 PM ah, then you can have that 5:20 PM then there would be a real reason to mention the transitive dependency 5:20 PM i.e. you want something from it Brian Stansberry 5:20 PM could it be declared in the top level block, even though the package is in the transitive dep? 5:20 PM i'm going off on tangents, but first i should have said... 5:21 PM Nice! Alexey Loubyansky 5:21 PM (EDITED) unless the package is installed by default, it has to be included explicitly using transitive element