Inject content of settings.xml into the artifact resolution. #1092
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
The pull request is currently at a state where Tycho successfully downloads the jars, but then fails when downloading the corresponding pom during the compilation phase. Does anyone have an idea what I'm missing? Stacktrace
|
This comment was marked as outdated.
This comment was marked as outdated.
|
@pzi-dsa this looks very interesting. Do you think you can add an integration test for this? There are already some for maven and updatesite authentication that might could be used as a basis? |
|
I've tried setting up an integration test similar to PasswordProtectedP2RepositoryTest. However it seems mocking a m2 repository is a little bit more complicated than a p2 repository. So clearly there is something native Maven does, that Tycho doesn't. I just can't figure out what... :/ Given that it works in m2e, I also looked at how it's done there. But there everything is managed by the IMaven interface, which also solves this via the call of injectAuthentication(...). |
I must confess that I assumed there is nothing to do specially as we use the maven resolver system. The only think I can think of is that somehow the ID is messed up and maven uses the ID to find the authentication... |
|
@pzi-dsa if there is a public available example I can also try to take a look, but I have no password-protected setup at hand here to test... |
|
I think I managed to get the integration test running. It turned out the GAV in the target platform didn't match the artifact in the repository. On the master, I get the following entry in my .m2 repository: And on my branch, the following: In the second case, the jar is also successfully stored in my local repository. Which is exactly what I was hoping for. |
|
Tycho injects the Maven artifacts into the model, and then maven tries to download them. In general, they should already be available locally then, but for the case of password-protected mirrors there might be a flaw. There is also some ongoing work to improve this. Can you explain what "It turned out the GAV in the target platform didn't match the artifact in the repository." mean here? |
The mock repository I created for the test only contains a single artifact, It has nothing to do with the problem at hand, just a mistake on my side. |
|
I think I managed to adapt the test case in such a way that it reproduces the stacktrace from my second comment. They are not identical, but both lead to the same cause, the inability to download the pom file from the local Maven repository, as shown in the lastUpdated file: If I set this draft to "Ready for review", it should start the test suite, right? Hopefully it will then fail with the same error. |
|
@pzi-dsa is this the error you are expecting? |
|
@laeubi I think that's exactly it! |
|
Alright, I think your previous code changes are not related to this failure and it would wonder me if they make anything better as we should inherit the maven settings but the maven resolution itself has a problem here, so if you like the starting point for debugging should be this should be the first place to check if something went wrong here (e.g. wrong/missing ids, no repositories injected at all / ...) and also a breakpoint at |
|
I finally got some time to revisit this pull request, and I think your suspicion was spot-on, @laeubi To quickly explain what's going on: Because those repositories are injected back into the Maven model, due to Issue #697, it then caused the seemingly unrelated stacktrace which had me stuck for quite a while. Meaning I "only" had to inject settings.xml into those repositories, whenever they are created. Thank you a lot for your help :) |
ghost
marked this pull request as ready for review
The error seems more like an Eclipse issue and unrelated to my changes.
And this warning only happens on Windows... Likely a problem when setting up the mock HTTP server, would be my guess. Though I don't see why this fails for the m2 test but not the p2 test. :-| |
For artifact repositories which have been specified in the target platform definition, Tycho creates a minimal instance, containing only an id and url, which is then injected back into the Maven model. In order to support e.g. authenticating against a private repository, it is necessary to also inject the user credentials, provided via the local settings.xml, into this instance. Otherwise accessing the referenced artifacts fails with a 401 - Unauthorized.
|
Github action failures are unrelated. |
|
@pzi-dsa thanks for the fix and for the test-case! Lets see if this improves the situation for you 👍 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When downloading Maven artifacts from e.g. a private repository, Tycho
needs to authenticate itself as a valid user, using the credentials
provided in the settings.xml file.
Otherwise the request most likely fails with a 401 - Unauthorized.
As context: We deploy some of our artifacts to a local Nexus. Currently, anonymous access is enabled, hence why Tycho can download them as dependencies for our product without problem. But at some point, we want to get rid of it, due to security requirements.
Tycho already supports authenticated access for p2 repositories, but for Maven repositories, the content of the settings.xml file is ignored.