SSLHandshakeException stacktrace from maven.java.net not actionable, possibly should not have been attempted
#4101
Comments
|
Just noting it here also, but there's a thread in Slack mentioning the same issue. Could potentially catch the exception from an OpenRewrite standpoint, but I'm also guessing that this likely appears directly from Maven as well for the same reasons. |
|
@shanman190 no, I don't see anything from Maven. Only OpenRewrite is complaining. |
|
That's interesting. @sambsnyd, do you have any opinions on how you'd like to see this handled? |
|
I wonder if OpenRewrite selects the repositories the same way as Maven. I wasn't able to find where these repositories came from exactly but I wouldn't expect them to be used if things are in Maven Central. |
|
I think it could be appropriate in rewrite-maven-plugin to check some of the common SSL-skipping parameters used in Maven builds and provide an appropriate http client in the execution context |
|
I’m not sure the problem is due to that really. For the other project, it was contacting another server that wasn’t responding at all. I think the problem is that you shouldn’t contact these servers at all in the first place. |
|
To further clarify: I'm not sure adding the Maven Central repository last is actually what Maven does by default. At least, not compared to repositories declared in dependencies of the project. Another option could be to not report any error when it's impossible to download the artifact. I mean I could see how you could maybe pile up the download errors and only log them if in the end we can't download the artifact from any repository? But I think getting a clear picture of the correct ordering is important, because in the case I had where some artifact somewhere was referencing a repository that was non-existent and timing out, it would make my build a lot slower if we try to resolve all artifacts with this repository first. |
I want to reiterate this. IIRC, java.net should not be used for anything at all anymore, really, see the notice at[1]. I assume they're keeping up their Nexus instance so as not to break anyone's build if you depend on artifacts from projects that for some reason haven't moved on to other maven repositories (like central). Unfortunately their SSL certificate has simply expired. I have personally emailed both the domain owner as well as the mail-address mentioned on [1]. Perhaps it would be for the better if they just opted to shut down said Nexus. |
|
It is used because some artifacts somewhere in the dependency tree has it. You can't drop it from existing artifacts. And I know that when resolving the dependencies of artifact1, if artifact1 has java.net as a repository, you might contact it... but my understanding was that we would hit Maven Central first and not last. What needs fixing is that we should either not contact it at all if in Maven Central as I think Maven resolves Maven Central by default first or we should ignore the error if we can find it in a later repositories. |
|
https://maven.apache.org/guides/mini/guide-multiple-repositories.html#repository-order It's possible that internal Maven code is out of sync with this, but the documentation kinda makes it seem like if Maven settings aren't used and some repository that contains the artifact isn't explicitly defined somewhere prior, then it should hit java.net (undesirably) by the order of the rules there. It also makes it seem like the default super pom comes after any local or parent poms, but before dependency poms. So it does seem like there may be some incorrect ordering within rewrite-maven as well. |
|
It is NOT ONLY a warning: It stops all processing when this error occures and nothing is transformed. Unusable stuff at all. |
I think you may have misunderstood. What I meant is that a conscious effort should be made to update dependencies such that we don't get any kind of (not even transitive) reference to the old maven.java.net repository. If we can't do that (because a dependency is not replaceable for instance), the effort should go into assisting the dependency to move on etc.
Ignoring the error if it's found in later repositories is what maven does I believe. It's an acceptable quick solution I think. If the logic used here comes from the maven code, perhaps the effort should be put into improving maven. FWIW: one of the things that has annoyed me in maven is that if in a dependency a specific repo is mentioned, maven contacts it for all dependencies it tries to resolve after, including local dependencies in multi-module projects and therefore leaking miniscule bits of information of your project to some repository. Ignore this aside as it's not relevant for this issue. |
|
@timtebeek and @sambsnyd this one feels pretty important. Do we simply need a carve out exclusion to never contact java.net? On the other point, I am pretty confident Maven Central is added last deep in the Maven code. |
|
That's not only java.net. I had the issues with some other repositories that were declared in some dependencies. And I don't recall having seen failures of artifacts being downloaded from these repositories first when using regular Maven so I'm not entirely sure the logic in OpenRewrite is right. |
|
I've had numerous issue with openrewrite because its clearly not doing things by the book. Pls get a Maven maintainer to look at how this project is working with Maven. |
|
@delanym FWIW, that is not my personal experience. Anyway, there are more pleasant ways to convey this message. |
|
I tried again on two of my projects to gather a bit more information. For https://github.com/quarkusio/quarkus-github-bot, I get the warning twice:
Unfortunately, there are no details about the requests in the warnings but what I find odd is that both are for snapshots repositories and the only snapshot version in this project is the version of the project itself (and I wouldn't expect it to try to download the modules from the project). I built the projects (regular
as the two contacted repositories. From what I can see the I have the same experience with https://github.com/quarkiverse/quarkus-github-app/ but I only have one warning there:
I remember having seen another project with I'm sorry, I don't have the time to dig more at the moment but I hope this could be helpful. |
|
Repositories are defined in the poms included in a JAR, like woodstox-core-6.5.1/META-INF/maven/com.sun.xml.bind.jaxb/isorelax/pom.xml <repositories>
<repository>
<id>releases.java.net</id>
<url>https://maven.java.net/content/repositories/releases/</url>
<layout>default</layout>
</repository>
<repository>
<id>jvnet-nexus-staging</id>
<url>https://maven.java.net/content/repositories/staging/</url>
<layout>default</layout>
</repository>
<repository>
<id>eclipse</id>
<url>http://download.eclipse.org/rt/eclipselink/maven.repo</url>
<layout>default</layout>
</repository>
</repositories>Why openrewrite would read this I don't know I'm not a Maven expert, but neither should you have to be. There's no shame in asking for help. We cant all be experts in every field, and Maven is a complex beast all by itself. |
|
@delanym I'm not part of this project so I only speak for myself but really, again, you can say the same things without being borderline insulting. Feedback is useful but there's really no need to be hostile. |
|
No hostility intended |
|
👋 I have the same issue as well. Is there a known workaround? This is blocking |
|
I have the same issue. It leads to a |
timtebeek
added
question
|
So we just did a new release yesterday that folks here might want to try out: https://github.com/openrewrite/rewrite-recipe-bom/releases/tag/v2.10.0 I've done a quick recipe run locally using this latest version and I had no issue getting recipe results from OrderImports against the above mentioned https://github.com/quarkiverse/quarkus-github-app/ just now This despite this warning that we surface, but does not break running recipes |
|
You are right. The execution-breaking error I referred to comes from dependencies using the |
|
Thanks for chiming in with that insight; good that recipe runs are at least not affected. That brings us back to the message Guillaume started with: that it's probably best to not show the full stacktrace if this is not affecting recipe runs in practice. With this PR we already have some work in progress that touches upon some of the same areas I propose we wait for the above PR to be merged and then reevaluate if we still have to change the reported stacktrace here. |
timtebeek
changed the title
|
@timtebeek I think the problem is more complex than just having a warning. See this comment: #4101 (comment) I think there is a problem in how the repositories are collected and their scopes. As these servers shouldn't even be contacted (and are not in a standard Maven run). FWIW, from the beginning in my case I had the warning but the recipes were applied. |
timtebeek
changed the title
SSLHandshakeException stacktrace from maven.java.net not actionable, possibly should not have been attempted
|
👋 I have the same issue as well. Is there a known workaround? But is not blocking rewrite:run |
Sorry to hear; would you be able to provide a minimal reproducer project? Despite the number of folks chiming I've not yet been able to reproduce the behavior where Edit: I now see you've edited your earlier remark: So runs are not blocked then? Just the call-out attempt that you'd like to see removed? |
|
Maybe a complication for issues like this is that OpenRewrite takes a long time to run a recipe on a large codebase. If there's any kind of error and then no activity it looks like the build is stuck. There's also no disk writes until the last moment. Is there some way to make the (Maven) plugin output more verbose or get it to write files immediately after processing them? |
I have noticed several warnings lately when updating various projects related to repositories not being available or not up to date.
As far as I can see, it's usually dependencies coming with exotic repositories declared and it seems that OpenRewrite resolves all of them (not sure if it's new but I noticed it only lately).
It generates big warnings in the output such as:
(This is just an example, I had another issue with some dependency in the classpath registering central.maven.org as a repository...)
Given there's nothing we can do about it as they come from external dependencies, I wonder if this should be debug logging instead?
At least for repositories coming from dependencies and not from the current project.
I have seen this lately in two different projects (and two different errors) so I suspect this might be more common than we think.
Thoughts?
The text was updated successfully, but these errors were encountered: