galleon failing to install wildfly 17.0.1.Final

[mikeadouglass]

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"

[mikeadouglass]

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?

[jaikiran]

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?

[brian.stansberry]

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.

[mikeadouglass]

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?