Adopt a "maven is leading" strategy for rascal resolution for external projects/jvms

[DavyLandman]

Introduction

In a recent session with @jurgenvinju and @PaulKlint we realized there is an opportunity -- created by integrating rascal-core and rascal-tutor back into rascal -- to always follow the rascal version that the user supplied in the pom.xml. This has the following benefits:

• Users get what they ask for
• We don't have to force the users to upgrade to the latest version of rascal just because they want to use a newer typechecker or VS Code
• We reduce the "weight" of the cyclic dependency on the rascal-maven plugin
• We can more easily configure the bootstrapping for the rascal project
• more in line with other projects that support multiple versions

Note: this issue is not about a compiler that can target different versions of the runtime or anything like that. When the compiler is ready, it will only support the runtime version it was compiled for.

Implementation decisions

The rest of this proposal tries to sketch out the fall out of this choice. The idea is that this will be a new feature, and we won't be supporting older version in this scheme.

rascal projects

• Users will have to configure a rascal version in the pom
• We'll have a fallback to help users with a new project (or a legacy one without a pom.xml)

rascal-maven-plugin

1. rascal:compile/tutor/console always start the rascal.jar defined in the projects pom.xml
2. This means we have to define a set of command line arguments that we think can remain stable for a while.
3. We should have a way to detect which version of command line arguments are supported by the rascal.jar in the pom.xml (some kind of version file maybe in the manifest?)
4. For the rascal project itself, the rascal-maven-plugin should get a parameter to define a "bootstrap" rascal version to use for the compilation/tutor phase. In some settings this can be an older version than N-1.

rascal

1. path config calculation gets a new flag: externalJVM or something of the sort. As for projects not in the current jvm it won't put the std on src/lib path, but respects the pom.xml.
2. contains a set of main functions to run the compiler & tutor
3. might get a few more extensions that enable the VS Code repl to start cleanly

rascal vs code extension

1. will still ship it's own version of rascal, purely for the IDE features (typechecking/rename/outline etc)
2. Will start the REPL for the rascal version defined in the pom.xml (this requires some changes to the way we start a rascal repl and it's integration to for example the debug adaptor protocol and our virtual file system connection)
3. The parametric server will have to fork a new JVM for every project/language, or at least for version of rascal dependency. (this takes some work, as we would make the current parametric server more of a forwarder to the actual server).
4. we might have to make some quick-fixes / warnings for the user in case their project setup is missing a rascal definition in the pom.xml

replace the std scheme

One of the biggest side-effect of this stragegy is that the std scheme will become incorrect. Since not all involved JVMs will have the same runtime version of rascal, the std for each of them points to a different jar. Since the std scheme currently fixes certain issues in the tutor, typechecker, ide an debugger we have to think of a new "fixed" path. After some discussion we've come up with the following scheme:

1. std will be replaced by a mvn://org.rascalmpl--rascal--<version> uri.
2. In most cases this is already possible, as the pom.xml will be leading and pointing to a jar in the local maven repo
3. If a interpreter is started with a rascal.jar (or target folder) that is not in the maven repo, we register a logical resolver for the specific version of rascal, and redirect that specific mvn uri to the one on the class path.

interplay between constructor of runtime & checking/compilation

The rough summary is: the JVM configuration is leading for your own runtime. So a tutor running in a jvm, follows the classpath of the JVM it runs in. But if we're responsible for starting a JVM (or a typecheck) for a different project, we always follow what is in the pom.xml.

Here is a small table with some examples:

Task	Class path is leading	pom.xml is leading
REPL startup	✅
Calculating REPL classpath (for a different jvm)		✅
Rascal LSP start	✅
Loading typechecker	✅
Calculating pathconfig for typechecker invocation:		✅
Tutor startup	✅
Calculating classpath for the tutor (for a different jvm)		✅

Tasks identified:

• [ ] change rascal-maven-plugin to only invoke the rascal.jar in a correct way (and translate back results
• [ ] update path config calculation on rascal to make sure we respect the pom.xml even for the rascal dependency, in case we're calculating a path config that is not for the current jvm
• [ ] develop versioned interface for rascal compiler & rascal tutor in the rascal.jar
• [ ] Adapt VS Code & rascal lsp to be able to start a repl a rascal version thats not the one shipped with VS Code
• [ ] Adapt VS Code Parametric Language server to become a forwarder and start a new actual parametric server per rascal version
• [ ] Provide quickfixes in VS Code for users with an outdated project setup
• [ ] Remove std (or at least its usage) and replace it with a mvn based uri