[jboss-jira] [JBoss JIRA] (WFLY-12915) Clean out unneeded provisioning boilerplate

[Brian Stansberry (Jira)]

     [ https://issues.redhat.com/browse/WFLY-12915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry resolved WFLY-12915.
-------------------------------------
    Resolution: Duplicate Issue


> Clean out unneeded provisioning boilerplate
> -------------------------------------------
>
>                 Key: WFLY-12915
>                 URL: https://issues.redhat.com/browse/WFLY-12915
>             Project: WildFly
>          Issue Type: Task
>          Components: Build System
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Major
>
> The current Galleon 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)