`SSLHandshakeException` stacktrace from `maven.java.net` not actionable, possibly should not have been attempted

[gsmet]

`SSLHandshakeException` stacktrace from `maven.java.net` not actionable, possibly should not have been attempted

[domariscampos-hotmart]

👋 I have the same issue as well. Is there a known workaround? But is not blocking rewrite:run

[iksaif]

👋 I have the same issue as well. Is there a known workaround? This is blocking rewrite:run to complete

[gsmet]

@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.

[gsmet]

@delanym FWIW, that is not my personal experience. Anyway, there are more pleasant ways to convey this message.

[Dzeri96]

You are right. The execution-breaking error I referred to comes from dependencies using the LATEST version.

[timtebeek]

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

• #4140

I propose we wait for the above PR to be merged and then reevaluate if we still have to change the reported stacktrace here.

[shanman190]

Just noting it here also, but there's a thread in Slack mentioning the same issue.

https://rewriteoss.slack.com/archives/C01A843MWG5/p1711020348961109?thread_ts=1711020348.961109&cid=C01A843MWG5

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.

[gsmet]

@shanman190 no, I don't see anything from Maven. Only OpenRewrite is complaining.

[shanman190]

That's interesting.

@sambsnyd, do you have any opinions on how you'd like to see this handled?

[gsmet]

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.

[sambsnyd]

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

[gsmet]

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.

[gsmet]

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.

https://github.com/openrewrite/rewrite/blob/main/rewrite-maven/src/main/java/org/openrewrite/maven/internal/MavenPomDownloader.java#L683-L688

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.

[javanegmond]

I think the problem is that you shouldn’t contact these servers at all in the first place.

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.

[1] https://www.java.net

[gsmet]

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.

[shanman190]

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.

[raman777]

It is NOT ONLY a warning: It stops all processing when this error occures and nothing is transformed.

Unusable stuff at all.

[javanegmond]

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.

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.
Since the whole java.net domain shouldn't have been used for a while it's pretty likely that somewhere along the dependency tree where it's referenced some kind of (transitive) dependency is also no longer under maintenance. Depending on unmaintained libraries is also a clear risk that should be avoided as much as possible.

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.

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.

[jkschneider]

@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.

[gsmet]

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.

[delanym]

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.

[gsmet]

@jkschneider

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:

[WARNING] Failed to access maven repository http://snapshots.repository.codehaus.org
[WARNING] Failed to access maven repository https://maven.java.net/content/repositories/snapshots

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 mvn clean install) with an empty repo to see if these repositories were contacted but I can only see:

[INFO] Downloading from central
[INFO] Downloading from sonatype-snapshots

as the two contacted repositories.

From what I can see the sonatype-snapshots is only called when resolving some Arquillian/Shrinkwrap stuff so it's not globally taken into account. My understanding is that the scope of the repositories declared in a dependency is very localized to resolving the dependencies of this particular artifact (not sure if it's transitive or not). It is contacted first, then as the dependencies are not snapshots, they can't be resolved and the dependencies is resolved from central in a second time.
Other than that, central is contacted first, even after this sonatype-snapshots was detected.

I have the same experience with https://github.com/quarkiverse/quarkus-github-app/ but I only have one warning there:

[WARNING] Failed to access maven repository https://maven.java.net/content/repositories/snapshots

I remember having seen another project with central.maven.org but I couldn't find it back.

I'm sorry, I don't have the time to dig more at the moment but I hope this could be helpful.

[delanym]

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.
Its the kind of issue that is so obviously wrong it suggests this project is not going through the right channels.

[gsmet]

@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.
Please keep things civil, provide feedback, I personally don't like to work in a hostile environment and I'm pretty sure other people around here don't either.

Feedback is useful but there's really no need to be hostile.

[delanym]

No hostility intended

[Dzeri96]

I have the same issue. It leads to a java.lang.IllegalStateException: Illegal state while comparing versions, or at least I assume that's the cause

[timtebeek]

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

mvn -U org.openrewrite.maven:rewrite-maven-plugin:run -Drewrite.activeRecipes=org.openrewrite.java.OrderImports

This despite this warning that we surface, but does not break running recipes

[INFO] --- rewrite:5.29.0:run (default-cli) @ quarkus-github-app-docs ---
[INFO] Using active recipe(s) [org.openrewrite.java.OrderImports]
[INFO] Using active styles(s) []
[INFO] Validating active recipes...
[INFO] Project [Quarkus - GitHub App - Parent] Resolving Poms...
[WARNING] Failed to access maven repository https://maven.java.net/content/repositories/snapshots
javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
    at sun.security.ssl.Alert.createSSLException (Alert.java:130)
    at sun.security.ssl.TransportContext.fatal (TransportContext.java:378)
...
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:206)
    at jdk.internal.reflect.DirectMethodHandleAccessor.invoke (DirectMethodHandleAccessor.java:103)
    at java.lang.reflect.Method.invoke (Method.java:580)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:283)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:226)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:407)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:348)
[INFO] Project [Quarkus - GitHub App - Parent] Parsing source files
[WARNING] There were problems parsing some source files, run with --errors to see full stack traces
[WARNING] There were problems parsing .github/workflows/build.yml
[WARNING] There were problems parsing .github/workflows/downstream.yml
[INFO] Project [Quarkus - GitHub App - Events] Parsing source files
[INFO] Project [Quarkus - GitHub App - Runtime] Parsing source files
[INFO] Project [Quarkus - GitHub App - Deployment] Parsing source files
[INFO] Project [Quarkus - GitHub App - Command Airline] Parsing source files
[INFO] Project [Quarkus - GitHub App - Command Airline - Runtime] Parsing source files
[INFO] Project [Quarkus - GitHub App - Command Airline - Deployment] Parsing source files
[INFO] Project [Quarkus - GitHub App - Testing] Parsing source files
[INFO] Project [Quarkus - GitHub App - Integration Tests] Parsing source files
[INFO] Project [Quarkus - GitHub App - Integration Tests - Testing Framework] Parsing source files
[INFO] Project [Quarkus - GitHub App - Integration Tests - App] Parsing source files
[INFO] Project [Quarkus - GitHub App - Integration Tests - Command Airline] Parsing source files
[INFO] Project [Quarkus - GitHub App - Documentation] Parsing source files
[INFO] Running recipe(s)...
[WARNING] Changes have been made to events/src/main/java/io/quarkiverse/githubapp/event/Discussion.java by:
[WARNING]     org.openrewrite.java.OrderImports
[WARNING] Changes have been made to events/src/main/java/io/quarkiverse/githubapp/event/WorkflowRun.java by:
[WARNING]     org.openrewrite.java.OrderImports
...
[WARNING] Please review and commit the results.
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary for Quarkus - GitHub App - Parent 999-SNAPSHOT:
[INFO] 
[INFO] Quarkus - GitHub App - Parent ...................... SUCCESS [  1.806 s]
[INFO] Quarkus - GitHub App - Events ...................... SUCCESS [  4.856 s]
[INFO] Quarkus - GitHub App - Runtime ..................... SUCCESS [  9.224 s]
[INFO] Quarkus - GitHub App - Deployment .................. SUCCESS [  3.832 s]
[INFO] Quarkus - GitHub App - Command Airline ............. SUCCESS [  0.007 s]
[INFO] Quarkus - GitHub App - Command Airline - Runtime ... SUCCESS [  0.728 s]
[INFO] Quarkus - GitHub App - Command Airline - Deployment  SUCCESS [  0.271 s]
[INFO] Quarkus - GitHub App - Testing ..................... SUCCESS [  0.489 s]
[INFO] Quarkus - GitHub App - Integration Tests ........... SUCCESS [  0.006 s]
[INFO] Quarkus - GitHub App - Integration Tests - Testing Framework SUCCESS [  0.364 s]
[INFO] Quarkus - GitHub App - Integration Tests - App ..... SUCCESS [  0.167 s]
[INFO] Quarkus - GitHub App - Integration Tests - Command Airline SUCCESS [  0.321 s]
[INFO] Quarkus - GitHub App - Documentation ............... SUCCESS [ 24.865 s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  47.627 s
[INFO] Finished at: 2024-04-25T19:58:57+02:00
[INFO] ------------------------------------------------------------------------

[timtebeek]

👋 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 rewrite:run is blocked. Would help towards getting this resolved, as we certainly wouldn't want anyone stuck on older versions.

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?

[delanym]

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?