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

Runtime artifact's POM repos aren't propagated to resolve the deployment deps #3289

Merged
merged 1 commit into from
Jul 24, 2019

Conversation

aloubyansky
Copy link
Member

Fixes #3268

@aloubyansky aloubyansky added this to the 0.20.0 milestone Jul 19, 2019
@aloubyansky
Copy link
Member Author

@gsmet could you please review it for me? From previous experience I don't think anybody else will :) Thanks.

}

public List<RemoteRepository> aggregateRepositories(List<RemoteRepository> dominant, List<RemoteRepository> recessive) {
return dominant.isEmpty() ? recessive : remoteRepoManager.aggregateRepositories(repoSession, dominant, recessive, false);
Copy link
Member

Choose a reason for hiding this comment

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

In which case do we have dominant and recessive repositories?

Copy link
Member Author

Choose a reason for hiding this comment

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

That occurs naturally in any Maven project given that there is a hierarchy of POMs each of which may include repositories. Since during tests we, unfortunately, loose the Maven build context, we have to initialize repos the Maven way ourselves, taking the repos from the default settings and then merging them into the target project's repos. Repos from the project's POM will be dominating.
Another use-case is when we test/build an app from an external artifact (integration of external tests, for example). In that case, the project that integrates the external artifact is going to be dominating.


private AppModel injectDeploymentDependencies(AppArtifact appArtifact, DependencyNode root, List<Dependency> managedDeps) throws AppModelResolverException {
DependencyNode resolvedDeps = mvn.resolveManagedDependencies(toAetherArtifact(appArtifact),
directMvnDeps, managedDeps, managedRepos, devmode ? new String[] { "test" } : new String[0]).getRoot();
Copy link
Member

Choose a reason for hiding this comment

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

Sorry to bother you with my dumb questions but trying to understand what's going on to make a real review :).

Why exactly do we exclude the test scope when in dev mode and not in the other modes?

Copy link
Member Author

Choose a reason for hiding this comment

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

When an app is compiled, every scope except test is available, which maps to our dev mode and that's how it's reflected in our code.
However, when the application is packaged provided and test scopes are filtered out by default. So, in that case, I am delegating to the default Maven resolver config that is taking care of that.

@lburgazzoli
Copy link
Contributor

@aloubyansky @gsmet anything missing to get this PR merged ?

@gsmet
Copy link
Member

gsmet commented Jul 24, 2019

@lburgazzoli no sorry, I am at a F2F so available as time permits.

I just read Alexey's answer and it makes sense.

Alexey, just wondering if maybe we should add a bit more comments for the special cases in this code. Because you have everything in mind but we don't :) (and even for you, in 4 months, it might get tricky).

That being said, it can be done in a subsequent PR so let's not block this one.

@gsmet gsmet merged commit be0b138 into quarkusio:master Jul 24, 2019
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.

Runtime artifact's POM repos aren't propagated to resolve the corresponding deployment deps
3 participants