-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Use ChainedLocalRepositoryManager
to support -Dmaven.repo.local.tail
#43352
Conversation
Thanks a lot for the contribution! @aloubyansky can you have a look? |
.../maven-resolver/src/main/java/io/quarkus/bootstrap/resolver/maven/BootstrapMavenContext.java
Outdated
Show resolved
Hide resolved
@aloubyansky Any pointers on how to test this? And on what parts of the documentation need to be updated? |
I guess create a couple of local Maven repos in some temp dir and init the resolver, such as in https://github.com/quarkusio/quarkus/blob/main/independent-projects/bootstrap/maven-resolver/src/test/java/io/quarkus/bootstrap/resolver/maven/test/BootstrapMavenContextTestBase.java? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@aloubyansky Added tests and fixed a few bugs that the tests helped me catch :)
I took the liberty to make a small change to BootstrapMavenContextTestBase.java
to make it easier to configure BootstrapMavenContext
, and had to adapt another test (PreferPomsFromWorkspaceTest.java
)
I gave some thought to the documentation changes, and maybe there isn't a need to update anything, given -Dmaven.repo.local.tail
is a feature of Maven itself, so actually it would be expected that it works out of the box with Quarkus. From this perspective, this PR is more like a "bug fix" then adding new stuff.
Let me know what you think. I converted the PR to "ready for review" :)
Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @tiagobento
Would you mind adding a test for multiple locations in the tail? Perhaps you want to use different artifacts for that. Also if the same version of the artifact is found in multiple locations, I suppose the first location in the list will win?
BTW, you could use txt
artifacts instead of actual binaries for test artifacts.
.../maven-resolver/src/main/java/io/quarkus/bootstrap/resolver/maven/BootstrapMavenContext.java
Outdated
Show resolved
Hide resolved
public void testValidTailViaConfig() throws Exception { | ||
final BootstrapMavenContext mvn = bootstrapMavenContextForProject("workspace-with-local-repo-tail", | ||
BootstrapMavenContext.config() | ||
.setLocalRepositoryTail(new String[] { M2_LOCAL })); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you explain why this one passes? In this case ignore availability
will be true
, correct?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the baseline test, the "happy path"... You're correct that ignoreAvailability
will be true
by default. It works because the artifact is there, thus is resolved.
Added two more tests:
Fixed the ArrayList creation with a fixed length. Kept the |
BootstrapMavenContext.config() | ||
.setLocalRepositoryTail(new String[] { M2_FROM_REMOTE })); | ||
|
||
assertNotNull(resolveOrgAcmeFooJar001(mvn)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tiagobento could you please explain this one. ignoreAvailability
is true
. Is it availability of artifacts that should be ignored?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure. So maybe the ignoreAvailability
name kind of gives the wrong idea of what it actually does, and maybe a more explicit, albeit verbose, name would be ignoreRemoteAvailability
? cc @cstamas
This flag is only applicable for dependencies that have been downloaded from a remote repository prior to being consumed as part of a tail
local repository ("tracked", in Maven Resolver's terminology) . See the _remote.repositories
file.
This particular test succeeds because maven.repo.local.tail.ignoreAvailability
ends up being true
, so even though org.acme:foo:jar:0.0.1 was supposedly initially resolved from a remote repository with id = some-repo-id
, this fact is ignored, and it being available in the local repository suffices. When maven.repo.local.tail.ignoreAvailability
is false, it fails. That case is exactly what is covered by testValidTailFromRemoteCheckingForAvailabilityViaSystemProp
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the explanation. The property name is indeed very confusing. It sounds like the meaning is "trust any remote repo" that provided an artifact.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"availability" in resolver means that tracked remote repository (by repoID) is available in the context artifact is asked for. So "remote" may come in as "remote repo ID is available in current context asking for artifact" :)
@tiagobento could you please squash the commits? Thanks. |
@aloubyansky Done. Thanks! |
🎊 PR Preview bddf9a3 has been successfully built and deployed to https://quarkus-pr-main-43352-preview.surge.sh/version/main/guides/
|
Status for workflow
|
Status for workflow
|
@aloubyansky Thanks for merging it! Is there a chance to get this back-ported to 3.15? I see the tag is already created for 3.15.0, but maybe for 3.15.1? My team is waiting for 3.15 to be out so we can upgrade from 3.8. Having this feature on the LTS release would be very valuable to us 🙏 Let me know and I'll send the PR if that's ok. Thanks again! |
I think it can be backported. I added a label, it'll be considered. Thank you and congratulations on your first contribution to Quarkus! It's a nice one, I'll use it in our tests. |
@aloubyansky Thanks! |
@aloubyansky Hi! I saw this missed 3.15.1 :( Any change it can get included in 3.15.2? |
It has the backport label, so yes, it will be considered |
Unfortunately, this has not been released yet in the wild as 3.16 has not been released and we want some bake time for it. Depending on when we release 3.15.2, it might miss it but if all goes with the patch well we will consider it for 3.15.3. (We try to have the patches in a released version before backporting them) |
@gsmet Understood. I'll keep an eye on 3.16 and the upcoming 3.15 patches. Thanks a lot for considering it and getting back to me here |
Hi Quarkus team! 👋 My first PR here!
(still draft as I didn't have time to go through all the contribution guidelines yet)maven-resolver
introduced Chained LRM a while back. This PR adds support to it, making it possible for Quarkus Maven Plugin to find dependencies on local repositories declared as tail.Tested locally with a project I have and it worked great, but still need to research how to create tests for it and update the relevant parts of the documentation.
All feedback is appreciated. Thanks!