4 Replies Latest reply on Oct 2, 2019 10:36 PM by Mike Douglass

    galleon failing to install wildfly 17.0.1.Final

    Mike Douglass Newbie

      This is the command I'm running and the output:

      ./galleon-4.0.3.Final/bin/galleon.sh install wildfly:17.0#17.0.1.Final --dir=wildfly-17.0.1.Final --layers=core-server,jms-activemq,core-tools
      Resolving feature-pack wildfly-core:current#9.0.2.FinalError: Install failed.
      * Failed to read galleon/universe/producer/wildfly-core/channels/current/maven-channel.xml
        * ParseError at [row,col]:[5,28]
      Message: unexpected content: element start{urn:jboss:galleon:maven:channel:spec:1.0}version-exclude-regexnull

      (Note it flashes up a bunch of messages which it overwrites - this is what's left when it fails)

       

      I've tried it on 2 systems Ubuntu and Red-hat and it fails on both.   I tried setting the debug level but it doesn't show anything extra

       

      This does get a bit weirder - it first showed up on the red-hat system this evening. There is another red-hat system which is supposed to be identical - and indeed appears to be. The build worked on that system and still works.

      However - what I just tried is removing the local maven repository on the one that works - and now it also fails on that system. So it appears I had something cached from about September 5th which keptit working.

       

      On all systems I'm using openjdk 11

      $JAVA_HOME/bin/java -version
      openjdk version "11.0.3" 2019-04-16 LTS
      OpenJDK Runtime Environment 18.9 (build 11.0.3+7-LTS)
      OpenJDK 64-Bit Server VM 18.9 (build 11.0.3+7-LTS, mixed mode, sharing)

      The red-hats say this:

      cat /etc/os-release
      NAME="Red Hat Enterprise Linux Server"
      VERSION="7.6 (Maipo)"
      ID="rhel"
      ID_LIKE="fedora"
      VARIANT="Server"
      VARIANT_ID="server"
      VERSION_ID="7.6"
      PRETTY_NAME="Red Hat Enterprise Linux Server 7.6 (Maipo)"
      ANSI_COLOR="0;31"
      CPE_NAME="cpe:/o:redhat:enterprise_linux:7.6:GA:server"
      HOME_URL="https://www.redhat.com/"
      BUG_REPORT_URL="https://bugzilla.redhat.com/"

      REDHAT_BUGZILLA_PRODUCT="Red Hat Enterprise Linux 7"
      REDHAT_BUGZILLA_PRODUCT_VERSION=7.6
      REDHAT_SUPPORT_PRODUCT="Red Hat Enterprise Linux"
      REDHAT_SUPPORT_PRODUCT_VERSION="7.6"


        • 1. Re: galleon failing to install wildfly 17.0.1.Final
          Mike Douglass Newbie

          I've managed to get around this by updating to galleon 4.0.4.Final

           

           

          However this raises a new issue (or 2).

           

           

          I'm providing a scripted quickstart install of an application which runs

          on wildfly. I'd assumed that specifying a specific version of galleon

          and a specific version of wildfly would provide some degree of

          stability. That's clearly not the case. I distributed that release about

          a month ago.

           

           

          I'm assuming that galleon is verifying an XML configuration file and

          failing on something it doesn't recognize.

           

           

          Can we not take a more SOAP like approach and just ignore unrecognized

          elements. I'm assuming that 4.0.3.Final would have continued to work.

           

           

          Failing that is there any approach which provides greater stability?

          • 2. Re: galleon failing to install wildfly 17.0.1.Final
            Jaikiran Pai Master

            Resolving feature-pack wildfly-core:current#9.0.2.FinalError: Install failed.

            * Failed to read galleon/universe/producer/wildfly-core/channels/current/maven-channel.xml

              * ParseError at [row,col]:[5,28]

            Message: unexpected content: element start{urn:jboss:galleon:maven:channel:spec:1.0}version-exclude-regexnull

            So it looks like some new element/attribute got added to the maven-channel.xml in a newer version of Galleon and the older version of Galleon (4.0.3) is trying to parse that file and (obviously) doesn't understand this new element/attribute in the XML. Looks like a genuine issue. Maybe brian.stansberry would know a bit more?

            • 3. Re: galleon failing to install wildfly 17.0.1.Final
              Brian Stansberry Master

              Sorry; that was my fault. I don't think there's any workaround besides using 4.0.4.

               

              aloubyansky I'm not sure how best to deal with this kind of situation. Making the parsing more lenient would prevent this kind of failure, but it would also mean that instance of the tool is not enforcing constraints the producer has placed on its channels.

               

              A possible mitigation for this kind of thing would be to avoid applying new configs to 'legacy' channels, e.g. the 9.0 channel of wildfly-core:

               

              wildfly-producers/pom.xml at master · wildfly/wildfly-producers · GitHub

               

              Perhaps that could work if the FPLs used in the feature packs to declare their dependencies used a more constrained channel? For example we have this for the wildfly FP for 17.0.1:

               

              <feature-pack xmlns="urn:jboss:galleon:feature-pack:2.0" location="wildfly@maven(org.jboss.universe:community-universe):current#17.0.1.Final">

                  <transitive>

                      <dependency location="wildfly-core@maven(org.jboss.universe:community-universe):current#9.0.2.Final">

                          <origin>org.wildfly.core:wildfly-core-galleon-pack</origin>

                      </dependency>

                  </transitive>

                  <dependencies>

                      <dependency location="wildfly-servlet@maven(org.jboss.universe:community-universe):current#17.0.1.Final">

               

              Those specify specific builds, but the 'current' channel. If the wildfly-core one used 9.0 instead of current, and the 9.0 channel spec did not include the version-exclude-regex, perhaps this problem would not occur?

               

              TBH I need to get clearer in my head what the best practices are re different channels.

              • 4. Re: galleon failing to install wildfly 17.0.1.Final
                Mike Douglass Newbie

                What I'd like to be able to rely on is a particular version of galleon working for all releases of wildfly at the point in which it is released.

                 

                My assumption was that 4.0.3.Final would always work for wildfly 17.0.1.Final because it was working at the time I built my system.

                 

                Another clue to the behavior was the way that galleon kept on working on the machine on which i had successfully built a week or so previously - until I removed the maven repository.

                 

                This suggests to me that the data galleon uses isn't versioned  - otherwise presumably my cached copy would have been updated.

                 

                For the moment I can produce a new release with 4.0.4.Final but I'm guessing that something like this is going to happen again down the road.

                 

                It's my feeling that people are going to make the same assumptions as I did. Another possibility for confusion is what happens if it doesn't break but it produces different results?