[jboss-jira] [JBoss JIRA] (WFLY-12915) Clean out unneeded provisioning boilerplate
Brian Stansberry (Jira)
issues at jboss.org
Mon Dec 30 18:17:23 EST 2019
[ https://issues.redhat.com/browse/WFLY-12915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Brian Stansberry updated WFLY-12915:
------------------------------------
Description:
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
was:
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
> 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)
More information about the jboss-jira
mailing list