Simplify declaration of module path in sbt build #10836
Conversation
Akirathan
added
CI: No changelog needed
Akirathan
requested review from
4e6,
JaroslavTulach and
hubertp
as code owners
| ), | ||
| streams.value.log, | ||
| shouldContainAll = true | ||
| moduleDependencies := { |
There was a problem hiding this comment.
Same format as libraryDependencies. No longer need to call this cryptic filterModulesFromUpdate methods ...
| GraalVM.modules ++ GraalVM.langsPkgs ++ logbackPkg ++ helidon ++ Seq( | ||
| "org.slf4j" % "slf4j-api" % slf4jVersion, | ||
| "org.netbeans.api" % "org-netbeans-modules-sampler" % netbeansApiVersion, | ||
| (`runtime-fat-jar` / projectID).value, |
There was a problem hiding this comment.
This is how you specify that you want to put runtime-fat-jar/target/classes directory on module-path. I have found no way to infer this directly.
There was a problem hiding this comment.
I like the approach. There is a buildNativeImage failure to be fixed. Hopefully straightforward.
| syntaxMod, | ||
| profilingMod | ||
| Test / moduleDependencies := { | ||
| GraalVM.modules ++ GraalVM.langsPkgs ++ GraalVM.insightPkgs ++ logbackPkg ++ helidon ++ Seq( |
There was a problem hiding this comment.
This looks pretty understandable! It is a format I hope to be able to work with.
There was a problem hiding this comment.
I am glad. More info in the scaladocs of JPMSPlugin
| modulePath := Seq.empty, | ||
| moduleDependencies := Seq.empty, | ||
| // modulePath is set based on moduleDependencies | ||
| modulePath := { |
There was a problem hiding this comment.
Do we still need to expose modulePath? Shouldn't that be hidden as an internal detail of JPMSPlugin?
There was a problem hiding this comment.
Unfortunately yes. There are still some places that directly access modulePath, like
Line 1307 in 906442f
Generally, accessing modulePath setting is needed whenever you would like to assembly your own cmd line options. modulePath is then very useful, as it is of type Seq[File], whereas moduleDependencies is of type Seq[ModuleID] and getting files from that is difficult.
JPMSPlugin handles Runtime/moduleDependencies
runtime-fat-jar has to be as Jar on module-path, not exploded.
* Ensure the annotation processor error message is not lost * Dont limit ContextBuilder in BenchProcessor to enso language * Add libraryDependencies on GraalVM.toolsPkgs to std-benchmarks * Add some dependencies to std-benchmarks - fixes compilation * Revert std-benchmarks project settings from #10836. runtime-fat-jar has to be as Jar on module-path, not exploded. * fmt
Closes #10726
Pull Request Description
Simplify declarations of module path in the whole sbt build script by introducing a new task key
moduleDependenciesthat has the same format aslibraryDependencies. Everything frommoduleDependencieswill be added on--module-pathby theJPMSPlugin.Note that it is not possible to derive module path directly from
libraryDependenciesas explained in the issue comment.Important Notes
Checklist
Please ensure that the following checklist has been satisfied before submitting the PR:
Scala,
Java,
TypeScript,
and
Rust
style guides. In case you are using a language not listed above, follow the Rust style guide.