Low transparency failure to resolve libraries

[linuswagner]

When Rascal tries to resolve libraries, we can encounter something like

WARNING: could not resolve dependency on: |lib://clair| because: |lib://clair|

even though, Clair is installed on the system.
It turns out that this can happen when the project that is loaded into the REPL causes errors:

In order to resolve a library function, Rascal tries to look up the name in mavenLibs to resolve it (assuming that we have no project of that name loaded). This variable is filled from the content of mavenClasspath which in turn is a result of the method getPomXmlCompilerClasspath:
IList mavenClasspath = getPomXmlCompilerClasspath(manifestRoot);

When mavenClasspath is empty, libraries can not be resolved and the warning is printed.

It turns out that one case where this happens, is when the project that we load into the REPL throws errors through Maven:
getPomXmlCompilerClasspath executes mvn commands and tries to parse the output. Because it does so very optimistic, errors in the execution of these commands get shadowed by the parser and just lead to an empty list that the method returns.

In my project, I got the follow output that getPomXmlCompilerClasspath tried to parse using the command mvn --batch-mode -o dependency:build-classpath -DincludeScope=compile:

[INFO] Scanning for projects...
[INFO] 
[INFO] ------------------< org.rascalmpl:mapper-experiments >------------------
[INFO] Building mapper-experiments 0.1.0-SNAPSHOT
[INFO]   from pom.xml
[INFO] --------------------------------[ jar ]---------------------------------
[WARNING] The POM for org.rascalmpl:mapper:jar:0.1.0-SNAPSHOT is missing, no dependency information available
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  0.155 s
[INFO] Finished at: 2024-01-14T13:25:11+01:00
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal on project mapper-experiments: Could not resolve dependencies for project org.rascalmpl:mapper-experiments:jar:0.1.0-SNAPSHOT: Cannot access usethesource (https://releases.usethesource.io/maven/) in offline mode and the artifact org.rascalmpl:mapper:jar:0.1.0-SNAPSHOT has not been downloaded from it before. -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException

Because the method only returns an empty list, this error is not reported to the user. As a consequence, they are unable to fix the project and get their project to run in the REPL, because of missing dependencies.

Proposed solution (other for other places where the output of another process is used): Make sure to check the exit code of the process (here, Process process = processBuilder.start(); and process.exitcode is indeed 1) and report the error of the underlying process to the user (or allow them to see what was executed to reproduce on their own).

---

Another problem
The line

String libProjectName = manifest.getManifestProjectName(manifest.manifest(dep));

also can fail silently: If there is no manifest file (for reasons that I'm also trying to understand myself at the moment), manifest.manifest(dep) is simply null, so libProjectName ultimately becomes the empty string and the mapping breaks as well.

[linuswagner]

That's a very nasty bug. I remember that at the beginning of my thesis, I tried multiple times to get my dependencies for my project imported, but I always got the import warning. Eventually, I got it to work and thought, I must have missed a few steps when creating the builds for the libraries.

(╯°□°)╯︵ ┻━┻

[linuswagner]

For completness: The origin of all this mess from my side was a wrong version (did not exist) in the pom.xml of the project I tried to load. Might help to reproduce this problem

[DavyLandman]

Yes, it's a bit sensitive right now. We've been trying to improve this part. I think the current idea of how to improve it is: #1886

[jurgenvinju]

Let's continue this here at #1916 ; the new mvn scheme can throw IOExceptions if stuff goes wrong and it has a unique name for a unique jar instead of the opaque lib:///name that could resolve to all kinds of locations.