Uploaded image for project: 'WildFly'
  1. WildFly
  2. WFLY-12915

Clean out unneeded provisioning boilerplate

    XMLWordPrintable

Details

    • Task
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Duplicate Issue
    • None
    • None
    • Build System
    • None

    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

      Attachments

        Issue Links

          Activity

            People

              bstansbe@redhat.com Brian Stansberry
              bstansbe@redhat.com Brian Stansberry
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: