Closed Akirathan closed 1 week ago
Related:
runner.jar
should be a modular jar that is on the system's module-path.
Rather than that runner.jar
(or rather just the language server JAR) should be a module JAR in Standard/Visualization/polyglot/java
module, loaded by its own ModuleLayer
which automatically delegates to (mostly empty ModuleLayer
representing the JDK - e.g. java.base
but no Truffle APIs or language implementations, etc.).
Pavel Marek reports a new STANDUP for today (2024-08-15):
Progress: - Starting to migrate engine-runner to JPMS module.
Pavel Marek reports a new STANDUP for today (2024-08-16):
Progress: - Do not run enterprise engine and stdlib benchmarks #10829.
JPMSPlugin
more automatic - https://github.com/enso-org/enso/issues/10726#issuecomment-2293325930Pavel Marek reports a new STANDUP for today (2024-08-19):
Progress: - Continue migration of our internal projects to JPMS modules.
module-info.java
from the compilation and compile it manually, but the real pain is to ensure that there are correct requires
statements in the module descriptor for Scala sources.
requires
statements in the module descriptor are not checked.scala.util.Try
, and fails. The only way to fix it is to add requires scala.library
to the module descriptor.java --validate-modules
does not help.
- add
requires scala.library
to the module descriptor.
Adding a dependency on Scala core library sounds like the correct fix.
Pavel Marek reports a new STANDUP for today (2024-08-20):
Progress: - Providing org.enso.scalalibs.wrapper
- a meta project that includes all the problematic Scala libraries.
module-info
.
JPMSPlugin
to simplify the build process. It should be finished by 2024-08-20.Pavel Marek reports a new STANDUP for today (2024-08-21):
Progress: - Migrating more internal projects to JPMS modules.
runtime-fat-jar
workaround. It should be finished by 2024-08-27.Pavel Marek reports a new STANDUP for today (2024-08-22):
Progress: - Still migrating more projects to JPMS modules and fixing compilation.
Pavel Marek reports a new STANDUP for today (2024-08-23):
Progress: - Found a way how to compile module-info.java
along with other Java sources and not as a standalone source.
language-server
.Pavel Marek reports a new STANDUP for today (2024-08-26):
Progress: - Wrappers for akka and zio libraries.
updateLibraryManifests
and buildEngineDistribution
already works!
runtime-integration-tests/test
and language-server/test
. It should be finished by 2024-08-27.Pavel Marek reports a new STANDUP for today (2024-08-27):
Progress: - Some tests already run in runtime-integration-test
.
TestLogProvider
inside logging-service-logback/Test
, etc.
Pavel Marek reports a new STANDUP for today (2024-08-28):
Progress: - enso --run test/Base_Tests
and enso --run test/Table_Tests
already works!
Pavel Marek reports a new STANDUP for today (2024-08-29):
Progress: - runtime-integration-tests/test
seems to work locally!
language-server/test
. It should be finished by 2024-09-03.Pavel Marek reports a new STANDUP for today (2024-08-30):
Progress: - Many language server tests already succeeds.
runtime-benchmarks
and std-benchmarks
, but after language-server
, that should not be so difficult. It should be finished by 2024-09-03.Pavel Marek reports a new STANDUP for today (2024-09-02):
Progress: - Fixing problem with non-functional DirectoryWatcher
Pavel Marek reports a new STANDUP for today (2024-09-03):
Progress: - language-server/test
fixed.
runtime-benchmarks/run
fixed.std-benchmarks/compile
.
Pavel Marek reports a new STANDUP for today (2024-09-04):
Progress: - Merged and fixed with develop
org.graalvm.polyglot.Context
is loaded by two different class loaders - investigating.Pavel Marek reports a new STANDUP for today (2024-09-05):
Progress: - Renaming PR almost green, failing on some network transients. Will merge tomorrow.
org.graalvm.polyglot.Context
is loaded twice.Pavel Marek reports a new STANDUP for today (2024-09-06):
Progress: - Our benchmark annotation processor generates sources.
Pavel Marek reports a new STANDUP for today (2024-09-09):
Progress: - Small interactive session with Jaroslav about annotation processor problems
ExecutionContext.hasContextEnabled
- https://github.com/enso-org/enso/issues/10702 It should be finished by 2024-09-11.Pavel Marek reports a new STANDUP for today (2024-09-11):
Progress: - Finally fixed annotation processing
Pavel Marek reports a new STANDUP for the provided date (2024-09-14):
Progress: - High level discussion about future of Engine/LS.
Pavel Marek reports a new STANDUP for today (2024-09-18):
Progress: - Marked the PR as ready for review
Pavel Marek reports a new STANDUP for today (2024-09-19):
Progress: - Fixing booting of language server, and project-manager tests
Pavel Marek reports a new STANDUP for today (2024-09-20):
Progress: - std libraries CI job is already green!
Pavel Marek reports a new STANDUP for today (2024-09-23):
Progress: - Fixing remaining tests, help from Hubert
Pavel Marek reports a new STANDUP for today (2024-09-24):
Progress: - With help of Hubert and Jaroslav, got all the other tests passing, along with some nice sbt refactorings
scala-compiler
dependency distributed. Will try to get rid of that. It should be finished by 2024-09-25.Pavel Marek reports a new STANDUP for today (2024-09-25):
Progress: - Last nits and reviews
Current suboptimal module architecture
runner.jar
is currently a fat plain jar (no a JPMS module) located inbuilt-distribution/component/runner/runner.jar
. System module-path is set tobuilt-distribution/component
.runner.jar
contains all the classes from language-server and their dependencies. It does not contain classes that are on module-path. The original motivation, implemented in https://github.com/enso-org/enso/pull/7991, was to make the transition to JPMS as quick and as simple as possible. The idea is roughly as follows:org.enso.runtime
module inEngineRunnerBootLoader
class.IsolatedClassLoader
that either loads classes fromrunner.jar
, or delegates to system class loader.IsolatedClassLoader
loads classes fromrunner.jar
, that is not on the module-path.This design, however, lead to many ugly hacks:
runner.jar
, like all the helidon modules. But we need to put them inside runtime's module-info so that the system class loader can lookup classes from these modules.Better module architecture
runner.jar
should be a modular jar that is on the system's module-path.IsolatedClassLoader
.