wildfly-extras/wildfly-channel

Library for WildFly Channel

wildfly-channel's Issues

When enabling debug, schema validation produces too much output

Context: Maven plugin
Enable debug with "-X" argument: mvn clean package -X
The console displays thousands of lines (channel content).
That is caused by :https://github.com/wildfly-extras/wildfly-channel/blob/main/core/src/main/java/org/wildfly/channel/ChannelMapper.java#L76
That calls: https://github.com/wildfly-extras/wildfly-channel/blob/main/core/src/main/java/org/wildfly/channel/ChannelMapper.java#L115

This makes debug output unusable.

Add contributing and other community docs to wildfly-channel

Add community docs:

• CONTRIBUTING.md
• good-first-issues
• CODEOWNERS.md

Expose Channel API to allow creation of channels resources and their YAML content

The galleon-maven-plugin currently generates a channel YAML file "by hand" in https://github.com/wildfly/galleon-plugins/blob/f1eb9591ee6384af7b092e60d4cfb20d04b2c290/maven-plugin/src/main/java/org/wildfly/galleon/maven/AbstractFeaturePackBuildMojo.java#L457.

This is not maintainable and does not enforce that the resulting YAML content is valid.
Instead such code should use the Channel API and the ChannelMapper.toYAML(Channel) method to generate valid YAML content

During version resolution, MavenVersionResolver ignores versions deployed locally even if the same version is available in remote

If a given version of an artifact is deployed in the local maven repository (i.e. it has a maven-metadata-local.xml file in the .m2/repository), this version is omitted from MavenResolver#getAllVersions even if one of the remote repositories contains this version.

This is because Maven only returns one repository matching a version (see https://github.com/apache/maven/blob/master/maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/DefaultVersionRangeResolver.java#L183C40-L183C40) and local repository is always the first to be checked.

When MavenResolver filters out local versions, those versions are getting removed

The preference of versions is not specified

The documentation states that "latest" version can be recognized, but does not state how it determines what "latest" is, if it sorts versions alphanumerically or uses another sorting criteria. This is determined by https://github.com/wildfly-extras/wildfly-channel/blob/main/core/src/main/java/org/wildfly/channel/version/VersionMatcher.java, but event the class itself is not documented.

Plesase provide documentation for version ordering with examples of version preference.

Cannot create instance of class org.wildfly.channel.maven.ChannelCoordinate

#74 refactored the ChannelCoordinate and removed the no-arg constructor.
This breaks integration with the Maven plugin that uses reflection to create a ChannelCoordinate instance.

The ChannelCoordinate class must define a no-arg construction with non-final parameters for Maven to be able to create these instances.

Version preference prefers RC version over GA

Given choice between 1.0.0.GA and 1.0.0.RC1, version matcher will evaluate 1.0.0.RC1 as the "latest".

Incorrect resolution of the latest manifest from G:A

When creating a channel instance with GA manifest coordinate, and multiple repositories like:

schemaVersion: "2.0.0"
repositories:
  - id: "MRRC"
    url: "https://maven.repository.redhat.com/ga/"
  - id: "brew"
    url: "https://download.devel.redhat.com/brewroot/repos/jb-eap-8.0-maven-build/latest/maven/"
  - id: "indy"
    url: "https://indy.psi.redhat.com/api/content/maven/hosted/pnc-builds/"
manifest:
  maven:
    groupId: "org.jboss.eap.channel"
    artifactId: "eap-8.0"
noStreamStrategy: "none"

the manifest may not be resolved to the correct version.

In case when multiple repositories from the list contain the latest manifest artifacts in different versions, like currently MRRC contains manifest version 1.1.1.GA-redhat-00002 and brew already contains 1.2.0.GA-redhat-00009, channel library picks the first resolved version of these two (so essentially the random one), instead of the latest. In effect it may get resolved to 1.1.1.GA-redhat-00002 which is not the latest.

This may be affecting all tooling that resolve channels - prospero, wildfly-channel-maven-plugin, wildfly-maven-plugin, ...

This may be affecting customers using advanced use cases, but probably not majority of customers using the basic use case where only the MRRC repository is used.

Cc @spyrkob @jmesnil

Add schemaName field to Channel

I'm proposing to add also the "schemaName" field, next to the "schemaVersion" that was added while ago.

It looks that apart from wildfly-channel YAML configuration files, there is also going to be a prospero YAML configuration file which defines other aspects of provisioning configuration. Currently it contains list of channels (specified via GAVs or URLs), and list of Maven repositories. Example of current prospero config:

channels:
    gav: "org.jboss.eap.channels:eap-8.0-beta:1.0.0.Beta-redhat-00001"
repositories:
  - "id": "central",
    "url": "https://repo1.maven.org/maven2/"
  - "id": "mrrc",
    "url": "https://maven.repository.redhat.com/ga/"
  - "id": "channel",
    "url": "file:///home/thofman/tmp/m2-repo"

It would help to avoid confusing one config file with the other if we specify schema names for each config. The proposal is to have e.g.:

schemaName: "wildfly-channel"
schemaVersion: "1.0.0" # already present
name: "Channel for org.jboss.eap:wildfly-ee-galleon-pack:pom:8.0.0.Beta-redhat-20220614\
  \ feature pack."
description: "Generated by org.wildfly.galleon-plugins:wildfly-galleon-maven-plugin\
  \ at 2022-06-14T16:21:17.793742Z"
streams:
  - groupId: "antlr"
    artifactId: "antlr"
    version: "2.7.7.redhat-7"
  - ...

and:

schemaName: "prospero"
schemaVersion: "1.0.0"
channels:
    gav: "org.jboss.eap.channels:eap-8.0-beta:1.0.0.Beta-redhat-00001"
repositories:
  - "id": "central",
    "url": "https://repo1.maven.org/maven2/"
  - ...

Specify the order of the channel serialisation to have the `stream` field always last

The validation of the YAML content does not require any order of the fields but if we always write the streams field last this allows for a simple way to append additional streams to a channel.

Allow configuring maven checksum policy via a system property

For development purposes, sometimes it is necessary to work with artifacts that don't have a checksum.

One use case I've found is when we are specifying the path of the local repository we want to use to store the artifacts resolved. This is useful to generate Maven Zip Repositories that we can use in an offline mode.

In such a case, the tooling fails because it is expected that the artifacts resolved had a checksum. I suggest using a system property to configure the default checksum policy, so developers can generate these repositories without requiring to build them with checksum enabled.

Suggested name: "org.wildfly.channel.maven.policy.checksum"

Add to org.wildfly.channel.MavenArtifct id of at least channel/repo

Channel ID/GAV and repo url is very useful info to report sort of BOM of artifacts that went into build.

Streams for artifacts with classifiers

Right now Stream is identified by groupId and artifactId only. This means that eg. org.wildfly.core:wildfly-cli and org.wildfly.core:wildfly-cli:client will always be on the same version and when one is updated, the other one has to be released as well.
Should those two represent two different streams or one stream?

Verify the integrity of components coming from channels

When a component is installed from a stream, we should have a way to verify its integrity.

We could add a sha256checksum that would be verify when the corresponding artifact is downloaded to verify that its content has not been modified.
This is only possible if a fixed version is defined and would not make sense with versionPattern.

The checksum is also tied to the type and classifier of artifacts retrieved (eg Galleon pack would need to verify their zip package) while jar dependencies would verify their jar package. A single GA can define multiple artifacts thanks to the classifier, classifier, if any, is taken into account as [classifier/]extension in the key.

streams:
  - groupId: org.wildfly
    artifactId: wildfly-galleon-pack
    version: 26.0.0.Final
    sha256checksum:
      zip: d06591ac1fa5871258a574abcd4cc06f8be28ad1
  - groupId: org.wildfly.core
     artifactId: wildfly-controller
     version:19.0.0.Final
     sha256checksum:
       jar: 1cdc99e86a0002d111e7e41cc6989ca83624cd62
  - groupId: org.wildfly.core
     artifactId: wildfly-cli
     version:19.0.0.Final
     sha256checksum:
       jar: 1cdc99e86a0002d111e7e41cc6989ca83624cd62
       client/jar: 2adc99e86a0002d111e7e41cc6989ca83624cd98

• If the sha256checksum section is not present (or there is no value for the given package type), the integrity of the component will not be verified.
• If version is not present and the sha256checksum is present, an error will be reported.

The maven-resolver should printout the source of the resolved channel

In VersionResolverFactory#resolveChannels, the code will resolve channels from various places:

• a URL
• a Maven artifact (and if the version is not set, it will first find the latest version

The location of these channels must be logged so that the user would be able to determine and verify if the channels were resolved from the proper URL/artifacts.

This enhancement would add a dependency to org.jboss.logging:jboss-logging to log these data at the INFO level

Combining multiple channels fails when `resolve-if-no-stream: maven-release` is used

Trying to provision with following channels:

---
schemaVersion: "2.0.0"
name: "SSHD open channel"
repositories:
  - id: "deployment-repo"
    url: "file:/home/thofman/Projects/mina-sshd/repo"
manifest:
  url: "file:/home/thofman/prospero/empty-manifest.yaml"
resolve-if-no-stream: maven-release
---
schemaVersion: 2.0.0
name: "EAP 8 Channel"
manifest:
  maven:
    groupId: "org.jboss.eap.channels"
    artifactId: "eap-8.0"
repositories:
  - id: "mrrc"
    url: "https://maven.repository.redhat.com/ga/"
resolve-if-no-stream: none

(For testing purposes the first channel repo can probably be an empty dir, and the first channel manifest URL has to reference an empty manifest.)

Tryting to provision with java -jar prospero-cli-1.1.6.Final-redhat-00001-shaded.jar install --profile eap-8.0 --dir eaptest-release --channel channels.yaml I get an error:

ERROR: No versioning information found in metadata.

If fails when the first channel (SSHD channel) is trying to resolve maven metadata for org.jboss.eap:wildfly-ee-galleon-pack. It should be OK that the first channel is not able to resolve it - it would be resolved by the "EAP channel" - and this resolution failure should be silently ignored.

Stack trace:

"main@1" prio=5 tid=0x1 nid=NA runnable
  java.lang.Thread.State: RUNNABLE
	  at org.wildfly.channel.maven.VersionResolverFactory$MavenResolverImpl.lambda$findLatestMetadataVersion$17(VersionResolverFactory.java:300)
	  at org.wildfly.channel.maven.VersionResolverFactory$MavenResolverImpl$$Lambda$199/0x00007f40d82a93e0.get(Unknown Source:-1)
	  at java.util.Optional.orElseThrow(Optional.java:403)
	  at org.wildfly.channel.maven.VersionResolverFactory$MavenResolverImpl.findLatestMetadataVersion(VersionResolverFactory.java:300)
	  at org.wildfly.channel.maven.VersionResolverFactory$MavenResolverImpl.getMetadataReleaseVersion(VersionResolverFactory.java:267)
	  at org.wildfly.prospero.galleon.CachedVersionResolver.getMetadataReleaseVersion(CachedVersionResolver.java:118)
	  at org.wildfly.channel.ChannelImpl.resolveLatestVersion(ChannelImpl.java:236)
	  at org.wildfly.channel.ChannelSession.findChannelWithLatestVersion(ChannelSession.java:266)
	  at org.wildfly.channel.ChannelSession.resolveMavenArtifact(ChannelSession.java:118)

Support a blocklisting of excluded artifact versions

Overview

When using an open channel, a situation may arise where certain artifacts are promoted to the channel and later discovered to be invalid. As it’s impossible to remove artifacts already deployed into a repository, a mechanism for blocklisting artifacts is needed.

The blocklist should be separate from the channel definition itself so that modifications to the list don’t require changes to the channel definition.

The proposal is to create a ‘blocklist.yaml’ artifact associated with a channel. It will contain a list of streams with excluded versions. When a channel resolves an artifact version, it will consult the latest version of the blocklist. Any versions listed in the blocklist are removed from the stream’s resolved versions and the latest remaining version is treated as the most recent stream version.

When new versions are added to the blocklist, a new version of the blocklist artifact will be promoted into the channel.

Format

The blocklist file contains a list of stream GAVs with multiple versions:

---
exclusions:
  - groupId: io.undertow
    artifactId: undertow-core
    versions: [2.2.18.Final, 2.2.17.Final]
…

The artifactId can use a wildcard syntax to refer to all the artifacts with the same groupId

---
exclusions:
  - groupId: io.undertow
    artifactId: “*”
    versions: [2.2.18.Final, 2.2.17.Final]

Resolving channel blocklist

A channel can reference blocklist via following header:

blocklist:
  groupId: org.channel.foo
  artifactId: blocklist
  versionPattern: “.*”

The blocklist is resolved when a channel is initialized. If no blocklist artifact can be resolved with supplied GAVs, the channel treats it as an empty blocklist.
A blocklist applies only to the channel that defined it, not its required channels.

Resolving artifact version

During artifact version resolution, a stream matching artifact GA is located in the channel. If the stream uses concrete versions, that version of the artifact is resolved and returned to the user.
If the stream uses versionPattern, the blocklist is checked for excluded versions. The excluded versions are removed from the set of available artifact versions before the latest remaining version matching the stream’s pattern is used to resolve the artifact.

If the blocklist excludes all available artifact versions, UnresolvedMavenArtifactException is thrown.

The blocklist is ignored when using resolveDirectMavenArtifact method.

Create a maven-resolver submodule

The core library defines a SPI to interact with Maven.

We can provide a maven-resolver module that would provide an implement of this SPI.
It might need additional configuration (to inject the remote repositories, etc.) to actually incorporate it in a Maven plugin/extension

Support bulk artifact resolution to speed up downloads

Aether's RepositorySystem supports bulk Maven operations. When resolving large amounts of artifacts those are more efficient then individual operations.

The proposal is to add following methods to the Channels API:

• Channel#resolveArtifacts(List<? extends ArtifactCoordinate>)
• ChannelSession#resolveDirectMavenArtifacts(List<? extends ArtifactCoordinate>)
• ChannelSession#resolveMavenArtifacts(List<? extends ArtifactCoordinate>)

Related to https://issues.redhat.com/browse/GAL-333 and https://issues.redhat.com/browse/WFGP-230

Support for "newest" stream version

In the spec.adoc, we have a requirement that in the streams section, either the version or the versionPattern field must be used.

I propose allowing neither to be present, and in that case resolving to the "newest" version of a stream. This is equivalent to specifying versionPattern: '.*'

This would be analogous to how the requires section behaves to channel requirements with a missing version field.

Versioning of channels yaml

In the event of changes to channel yaml specification, it might be a good idea to start versioning the specification and keep intended specification version in the yaml file. That way we can better ensure backwards compatibility.

Fix link to json-schema

wildfly-channel/core/src/main/resources/org/wildfly/channel/v1.0.0/schema.json

Line 3 in e1410ae

"$schema": "http://json-schema.org/draft/2019-09/schema#",

Using online tools (https://www.liquid-technologies.com/online-schema-to-json-converter) to generate JSON from schema, you get an error unless you set:

"$schema": "https://json-schema.org/draft/2019-09/schema"

Advanced Maven resolution strategies

Currently channels require each distinct groupId to be listed separately. In case of open channels, limiting versions to known pattern, it means a long list of streams with the same artifactId (*) and versionPattern (eg. .*.Final).

It would be easier to be define a catch-all stream that would be applied to all streams not explicitly defined. For example:

- groupId: '*'
   artifactId: '*'
   versionPattern: '.*.Final'

Support versionPatterns in blocklists

It should be possible to specify the blocked versions as a versionPattern similarly to streams in the manifest.

The blocklist should allow to define a list of blocked versions AND a pattern in which case the version would be blocked if it's matched by either.

Optionally - support multiple versionPatterns per block, to simplify more complex cases.

Example blocklist entry:

blocks:
  - groupId: "org.test"
     artifactId: "test-one"
     versions:
        - "1.0.0"
        - "1.0.1"
     versionPattern: "2\\..*"

HttpProxy cannot set setURLStreamHandlerFactory when Prospero is used under a modular environment.

When Prospero runs in a modular environment HttpProxy will generate always a warning since JBoss Modules already configures the URL.setURLStreamHandlerFactory

This is shown for example when Prospero is used under the server integration, where the update command generates the following warning:

17:36:45,715 WARN  [org.wildfly.channel.proxy.HttpProxy] (management-handler-thread - 1) Unable to URL.setURLStreamHandlerFactory: java.lang.Error: factory already defined
	at java.base/java.net.URL.setURLStreamHandlerFactory(URL.java:1232)
	at org.jboss.prospero//org.wildfly.channel.proxy.HttpProxy.setup(HttpProxy.java:74)
	at org.jboss.prospero//org.wildfly.channel.ChannelMapper.<clinit>(ChannelMapper.java:69)
	at org.jboss.prospero//org.wildfly.prospero.model.ProsperoConfig.readConfig(ProsperoConfig.java:77)
	at org.jboss.prospero//org.wildfly.prospero.api.InstallationMetadata.loadInstallation(InstallationMetadata.java:93)
	at org.jboss.prospero//org.wildfly.prospero.actions.UpdateAction.<init>(UpdateAction.java:57)
	at org.jboss.prospero//org.wildfly.prospero.spi.ProsperoInstallationManager$ActionFactory.getUpdateAction(ProsperoInstallationManager.java:321)
	at org.jboss.prospero//org.wildfly.prospero.spi.ProsperoInstallationManager.findUpdates(ProsperoInstallationManager.java:120)
	at [email protected]//org.wildfly.core.instmgr.InstMgrListUpdatesHandler$1.execute(InstMgrListUpdatesHandler.java:134)
	at [email protected]//org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:1065)
	at [email protected]//org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:786)
	at [email protected]//org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:477)
	at [email protected]//org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1450)
	at [email protected]//org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:449)
	at [email protected]//org.jboss.as.controller.ModelControllerImpl.lambda$executeForResponse$0(ModelControllerImpl.java:259)
	at [email protected]//org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:304)
	at [email protected]//org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:270)
	at [email protected]//org.jboss.as.controller.ModelControllerImpl.executeForResponse(ModelControllerImpl.java:259)
	at [email protected]//org.jboss.as.controller.ModelControllerImpl.executeOperation(ModelControllerImpl.java:253)
	at [email protected]//org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:236)
	at [email protected]//org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:239)
	at [email protected]//org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:161)
	at [email protected]//org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
	at [email protected]//org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:328)
	at [email protected]//org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:285)
	at [email protected]//org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254)
	at [email protected]//org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225)
	at [email protected]//org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:157)
	at [email protected]//org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
	at [email protected]//org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
	at [email protected]//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
	at [email protected]//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1990)
	at [email protected]//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
	at [email protected]//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
	at java.base/java.lang.Thread.run(Thread.java:834)
	at [email protected]//org.jboss.threads.JBossThread.run(JBossThread.java:513)

This issue could be affecting the behaviour added by #208

Version compare seems skewed for case like 1.9.2.Final-redhat-00001->1.9.2.redhat-00001

As per above.

Verify manifest ID has only valid characters

When parsing manifest YAML, verify the ID consists of alphanumeric + (-_:) only

Missing testcases for multiple channels in one channel file

We have example file in src/test/resources/channels/multiple-channels.yaml, but no tests are checking that the library is able to parse it.

Add more wicked version tests to ensure it works

The SP....-channel-4 stuff:
https://github.com/jmesnil/wildfly-channel/blob/main/core/src/test/java/org/wildfly/channel/version/VersionMatcherTestCase.java#L210

Pass the base version in ChannelSession.resolveMavenArtifact method

The current signature of the method is:

 resolveMavenArtifact(String groupId, String artifactId, String extension, String classifier)

It should be updated to be able to passe a required baseVersion that would be the current version of the artifact from which we want to resolve.
In the current state of the library, this would not be used but this will be required for future work (such as being able to determine different "latest" version of the same GA as described in #35).

The new signature of the method would be:

 resolveMavenArtifact(String groupId, String artifactId, String extension, String classifier, String baseVersion)

Clarification on Stream.version

In the javadoc of Stream.version, it says that the version can be a list of comma-separated versions:

wildfly-channel/core/src/main/java/org/wildfly/channel/Stream.java

Line 50 in e1410ae

* This must be either a single version (e.g. "1.0.0.Final") or a list of comma-separated versions

but in the json schame, it says that: This must be either a single version.

wildfly-channel/core/src/main/resources/org/wildfly/channel/v1.0.0/schema.json

Line 79 in e1410ae

"description": "Version of the stream. This must be either a single version. Only one of version, versionPattern must be set.",

We need to keep the version requirement consistent in the 2 places above.

Parralel resolution of available versions

Currently when using open channels (versions are specified by versionPattern), lot of time is spend on resolving available versions.

For demonstration, it takes about 30 seconds to provision wildfly-core (measured when all artifact files were already present in local maven cache). Of these 30 seconds, more then 20 seconds is spent in the ChannelSession#splitArtifactsPerChannel() method which performs the versions request to remote maven repositories (=> large number of http requests to obtain repository metadata).

I tried a simple experiment where the versions were resolved in a parallel stream using 10 threads. This reduced the installation time from 30 seconds to 10 seconds. The version resolution work now takes only around 2-3 seconds.

Can the channel library do parallel version resolution?

Name field is both required and optional

Specification lists name property as both optional and required. This is (based on JSON schema) most probably a formatting error.

Proposed fix in #77

Unknown properties in YAML file should not prevent to parse the file

Currently, if there is an unknown property in the YAML content, the ObjectMapper will fail with an UnknownProperty exception.
This is too strict, we can be liberal in what we accept and instead ignore any fields that is not known and validated by the JSON schema.

Splitting channel metadata into Channel and Manifest files

Splitting the Channel definition into Channel and Manifest files.

Channel contains static information - repositories, vendor, etc while Manifest contains streams definition

The retry logic in the VersionResolver fails if one of the repositories is unavailable

When resolving artifact from two or more repositries, if one of those is returning error code different then 404 (e.g. 503), the request will fail even though the other repository contains this artifact.

Example

            final Channel channel = new Channel.Builder()
                    .addRepository("public-ga", "http://localhost:8888/")    // always returns 503
                    .addRepository("mrrc", "https://maven.repository.redhat.com/ga/")
                    .setManifestCoordinate(new ChannelManifestCoordinate("org.jboss.eap.channels", "eap-8.0"))
                    .build();
            final ChannelSession channelSession = new ChannelSession(List.of(channel), new VersionResolverFactory(system, session));

Exception:

org.wildfly.channel.ArtifactTransferException: org.jboss.eap.channels:eap-8.0/maven-metadata.xml failed to transfer from http://localhost:8888/ during a previous attempt. This failure was cached in the local repository and resolution will not be reattempted until the update interval of public-ga has elapsed or updates are forced. Original error: Could not transfer metadata org.jboss.eap.channels:eap-8.0/maven-metadata.xml from/to public-ga (http://localhost:8888/): status code: 503, reason phrase: Service Unavailable (503)

	at org.wildfly.channel.maven.RetryHandler$RetryCounter.addRetry(RetryHandler.java:151)
	at org.wildfly.channel.maven.RetryHandler.attemptResolveMetadata(RetryHandler.java:116)
	at org.wildfly.channel.maven.VersionResolverFactory$MavenResolverImpl.getAllVersions(VersionResolverFactory.java:152)
	at org.wildfly.channel.maven.VersionResolverFactory$MavenResolverImpl.resolveChannelMetadata(VersionResolverFactory.java:263)
	at org.wildfly.channel.ChannelImpl.resolveManifest(ChannelImpl.java:200)
	at org.wildfly.channel.ChannelImpl.init(ChannelImpl.java:85)
	at org.wildfly.channel.ChannelSession.<init>(ChannelSession.java:90)
	at org.wildfly.channel.ChannelSession.<init>(ChannelSession.java:64)
	at org.wildfly.prospero.api.TestResolver.downloadAndUnzipRemoteArchive(TestResolver.java:87)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:578)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
	at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
	at org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
	at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
	at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
	at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
	at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
	at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:69)
	at com.intellij.rt.junit.IdeaTestRunner$Repeater$1.execute(IdeaTestRunner.java:38)
	at com.intellij.rt.execution.junit.TestsRepeater.repeat(TestsRepeater.java:11)
	at com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:35)
	at com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:232)
	at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:55)
Caused by: org.eclipse.aether.transfer.MetadataTransferException: org.jboss.eap.channels:eap-8.0/maven-metadata.xml failed to transfer from http://localhost:8888/ during a previous attempt. This failure was cached in the local repository and resolution will not be reattempted until the update interval of public-ga has elapsed or updates are forced. Original error: Could not transfer metadata org.jboss.eap.channels:eap-8.0/maven-metadata.xml from/to public-ga (http://localhost:8888/): status code: 503, reason phrase: Service Unavailable (503)
	at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.newException(DefaultUpdateCheckManager.java:331)
	at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.checkMetadata(DefaultUpdateCheckManager.java:293)
	at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolve(DefaultMetadataResolver.java:303)
	at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolveMetadata(DefaultMetadataResolver.java:180)
	at org.apache.maven.repository.internal.DefaultVersionRangeResolver.getVersions(DefaultVersionRangeResolver.java:198)
	at org.apache.maven.repository.internal.DefaultVersionRangeResolver.resolveVersionRange(DefaultVersionRangeResolver.java:148)
	at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveVersionRange(DefaultRepositorySystem.java:260)
	at org.wildfly.channel.maven.VersionResolverFactory$MavenResolverImpl.lambda$getAllVersions$0(VersionResolverFactory.java:154)
	at org.wildfly.channel.maven.RetryHandler.attemptResolveMetadata(RetryHandler.java:96)
	... 33 more

ChannelSession.resolveArtifact -> extension maybe null in reality cant be.

https://github.com/jmesnil/wildfly-channel/blob/main/core/src/main/java/org/wildfly/channel/ChannelSession.java#L61
Furthermore it equates to MavenDependency.type. Not sure why its renamed, but its tad confusing.

Channel API cant handle multiple versions of same artifact

For instance EAP has distinct tests for hibernate:

• 4.1
• 4.2
• 4.3
• 5.1

There is no way to lookup muzzled versions, unless you ignore channels and do plain maven lookup.

Required channel load order

Specification says that

The channels will be searched for a stream that matches the groupId/artifactId of the artifact. If the channel requires other channels, these will be searched first in their listed order.

The first stream that is found matching the groupId/artifactId will be used to determine the version of the artifact to pull.

This implies that when multiple channels are required and they all stream the same artifact, the version of the artifact from the first defined stream (according to order in streams section) should be used.

But according to tests. it seems that the newest version of the artifact is used instead.

org.opentest4j.AssertionFailedError: 
Expected :1.2.0.Final
Actual   :2.0.0.Final
...
	at org.wildfly.channel.ChannelWithRequirementsTestCase.testChannelMultipleRequirements(ChannelWithRequirementsTestCase.java:444)
...

Related tests added in #80

Use matrix builds in the 'main.yaml' GitHub Actions workflow; test SE 11, 17, 21

Test with the 3 LTS Java SE versions that WildFly supports.

Making SE 21 a preferred choice, on par with SE 17 or at least SE 11, is a general WildFly goal for the first half of 2024. So anywhere we can we should run tests using it. SE 17 is our current recommended version so we should test with that as well.