Daniel Chao

Currently failing test (can you see the CI job?): org.pkl.codegen.java.CliJavaCodeGeneratorTest ``` org.opentest4j.AssertionFailedError: expected: "org.pkl.config.java.mapper.org.mod1\#Person=org.Mod1$Person org.pkl.config.java.mapper.org.mod1\#ModuleClass=org.Mod1" but was: "#Java mappings for Pkl module `org.mod1` #Thu Feb 22 21:45:46 UTC 2024 org.pkl.config.java.mapper.org.mod1\#ModuleClass=org.Mod1...

Do you see the "tests" tab? That's what I use to filter out the noise. Probably fine to get rid of `--stacktrace` from these PRBs though.

On second thought, I think let's keep `--stacktrace`. It's verbose, but the test tools help, and it's extremely helpful the few times where we actually do need it.

This means that there was a conflict when applying the `graalVm23.patch` file. You can use `git apply --reject patches/graalVm23.patch` to apply the patch on a file-by-file basis to figure out...

RE: Java 11: TBD. This is still something we are coming up with an answer for. But, let's not make any build changes until we have an answer here. If...

> @bioball How can we move forward with updating Pkl's dependencies and keeping them up-to-date? Hold off on this and also #350 for now until we figure out our Java...

FYI--it's possible to define an in-language renderer; a renderer doesn't need to be part of the standard library. For an example of an in-language renderer, see [pkl.toml](https://github.com/apple/pkl-pantry/blob/main/packages/pkl.toml/toml.pkl)

Thanks! Will review this after #227 is merged. > Test package zip files are created with Gradle's Zip task, so perhaps something changed there. (I think it would be better...

@translatenix can you rebase again? Thanks!

> Can this be done in a separate PR? "build" is no worse than buildDir. Fine by me; will submit that patch as a follow-up