Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[GAL-290] MavenChannel.resolve should validate any build specified in… #268

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

bstansberry
Copy link
Contributor

… the FPL against the builds provided by the channel

https://issues.jboss.org/browse/GAL-290

This goes beyond the specific issue in that it should catch other cases where the specified build does not match what the channel provides (frequency or version range.)

This isn't a particularly elegant solution, but it seemed like adding an overloaded resolve method to MavenRepoManager to pass in the channel's various constraints would end up with an impl that does much the same kind of thing.

@aloubyansky or @jfdenise if you have any suggestions for how to test this please let me know. I added tests for GAL-280 that involve specifying a particular build but they must not be exercising the GAL-290 call path.

… the FPL against the builds provided by the channel
@@ -115,7 +115,22 @@ public Path resolve(FeaturePackLocation fpl) throws MavenUniverseException {
artifact.setVersionRange(versionRange);
producer.getRepo().resolveLatestVersion(artifact, getFrequency(fpl), versionIncludePattern, versionExcludePattern);
} else {
artifact.setVersion(fpl.getBuild());
String build = fpl.getBuild();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Couldn't we simply check whether the specified build matches the version patterns of this channel instead?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@aloubyansky We could but that doesn't deal with the user providing a build that is outside the version range or frequency of the channel.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants