oyvindberg
Allow setting jvm on a per project basis
Bleep seems very interesting to me, and I'd like to use it as the build tool in my project Slinc. One thing that Slinc needs, that no build tool provides at present, is per-project JVM settings.
Slinc has subprojects in it that target specific jvms, putting jvm specific usage of the preview/incubator status jvm feature "foreign api". The code in these projects is naturally JVM specific: j17 can only be built on Java 17, j19 on Java 19, and so on.
Bleep's support for setting the JVM in the build file is a step towards that, but if it could be told to compile j19 with a specific java 19 that would be the best option for me.
It's going to be a "maybe" for now. Compiling for different jvms means starting multiple bloop servers, one for each JVM. In itself this is not that bad, but then nothing in the model prevents dependencies between say jvm19 module and a jvm17 module. That would require bleep to duplicate a lot of task graph things from deep inside bloop. I don't think the added complexity is anywhere near worth it for a niche use case.
What I think is a better way forward is to use build rewrites to use a transformed variant of the build for another JVM. Theoretically we could mount these rewritten builds in an IDE, though some glue code is missing there.
Currently you can compile, test, publish and so on such a transformed build.
If you decide to try that right now, i think the exposed API will let you change pretty much everything except JVM, but i can find either a workaround or a patched version if you're keen on trying out this approach.
Can you point me in the direction of these rewrites? I'm also trying to put together a plugin to add scoverage reports
I think I have a good handle on the BuildTransformers now after making a ScoverageReport plugin using them, but I don't think they'll do what I need done.
I would say that isn't bleep's fault, cause currently no Scala build system can do what I need done for my project.
The structure of my project is as follows:
- core - JVM agnostic
- j17 - java 17 specific
- j19 - java 19 specific
- runtime - JVM agnostic
j17 and j19 depend on core, while runtime depends on j17 and j19. The runtime project is fairly simple and exists to choose j17 or j19 based on what jvm the user is running (both j17 and j19s classes are loaded, but since only the correct one is used, you don't get classnotfound or bytecode exceptions).
This makes slinc rather painful to build and develop. Compiling or testing the whole project is a multi-step process involving switching between jvms and compiling/testing each subproject seperately. At this point it feels like splitting them up into seperate repositories will be the final solution, though that introduces the pain of having to use publishLocal while developing core/j17/j19/runtime. That's an especially nasty problem when using dynver :face_exhaling:
Have you tried using the -release JVM flag? This should set the JVM in the correct compatiblity mode, and make previous jvms classes not available, then you can always build using the newest JVM.
--release is helpful for some things like core and runtime, but doesn't help on j17 and j19 because in java 19, the classes for java 17's foreign api no-longer exist. This means that java 19 in --release 17 mode will fail to compile j17 with errors about "📕 BSP: j17 value foreign is not a member of jdk.incubator [value => 8]"
That's an especially nasty problem when using dynver
Why would publishLocal with dynver be a nasty problem? Isn't it the other way around that these two are helpful solutions to your problem?
Why would publishLocal with dynver be a nasty problem? Isn't it the other way around that these two are helpful solutions to your problem?
Aligning and updating the versions between projects quite a bit of work mid-development. At least it has been in my experience.