[jboss-jira] [JBoss JIRA] (WFLY-12914) Upgrade Galleon to 4.2.1.Final and the wildfly-galleon-plugins to 4.2.2.Final; clean out unneeded provisioning boilerplate

[Brian Stansberry (Jira)]

Brian Stansberry created WFLY-12914:
---------------------------------------

             Summary: Upgrade Galleon to 4.2.1.Final and the wildfly-galleon-plugins to 4.2.2.Final; clean out unneeded provisioning boilerplate
                 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


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
  



--
This message was sent by Atlassian Jira
(v7.13.8#713008)