The current version of the kotlin-gradle plugin is not compatible with
Gradle 9.1, causing error `java.lang.NoSuchMethodError:
'org.gradle.api.Project org.gradle.api.artifacts.ProjectDependency.getDependencyProject()'`
Also, the Kotlin 2.0 language target is deprecated as of Kotlin 2.2.
Currently, in order to update a pkl-doc documentation site,
almost the entire existing site is read in order to update metadata
like known versions, known subtypes, and more.
For example, adding a new version of a package requires that the
existing runtime data of all existing versions be updated.
Eventually, this causes the required storage size to balloon
exponentially to the number of versions.
This addresses these limitations by:
1. Updating the runtime data structure to move "known versions" metadata
to the package level (the same JSON file is used for all versions).
2. Eliminating known subtype and known usage information at a
cross-package level.
3. Generating the search index by consuming the previously generated
search index.
4. Generating the main page by consuming the search index.
Because this changes how runtime data is stored, an existing docsite
needs to be migrated.
This also introduces a new migration command, `pkl-doc --migrate`,
which transforms an older version of the website into a newer version.
In the original implementation the `org/pkl/commons/cli/PklCARoots.pem` resource is resolved relatively to the classloader associated with the class returned by `javaClass`. However, since this is an extension method for `HttpClient.Builder`, it means calling `javaClass` on the builder instance, which is actually defined in the system classpath.
Because of this, if the Pkl class is loaded by a different classloader compared to the one which contains JDK classes, which is totally possible in certain scenarios (e.g. with Gradle), then this resource resolution will fail.
The solution is to resolve `javaClass` against `this@CliCommand`, to use the classloader which loaded the jar with the `CliCommand` class to find the CA resource.
Some systems require junit report to be in a single file. For example `bazel` https://bazel.build/reference/test-encyclopedia needs single file to be available in `XML_OUTPUT_FILE` path.
To avoid implementing junit aggregation in pkl wrappers in different places this PR instead adds a `--junit-aggregate-reports` flag to return all junit reports as a single file.
Additional flag `--junit-aggregate-suite-name` is added to allow overriding global test suite name from default `pkl-tests`
* Update dependencies
1. Remove */gradle.lockfile files
2. Run `gradle updateDependencyLocks` and commit
* Update multi-JDK testing to use simple Test task, add junit-platform-launcher to dependencies
- Don't use JvmTestSuite (we don't use another test runner, we use the same classpath)
* Add junit-platform-launcher to libs (prevent an issue where junit-engine and junit-launcher can fall out of sync)
This adds logic to build and publish the other executables related to Pkl.
These are:
* pkl-doc
* pkl-codegen-kotlin
* pkl-codegen-java
pkl-codegen-kotlin and pkl-codegen-java are published as executable JARs, whereas pkldoc is published both as an executable JAR, and also native executables (matching the set of os/arch supported by Pkl).
The reason this only publishes executable JARs for pkl-codegen-kotlin and pkl-codegen-java is because we expect that the Java requirement is not a problem for these users, and that the native executable provides negligible added value.
As part of this, the following changes are made:
* Introduce `pklJavaExecutable` plugin, which sets up building and publishing of executable JAR.
* Introduce `pklNativeExecutable` plugin, which sets up building and publishing of native executables.
* Introduce `NativeImageBuild` Gradle task, which knows how to build native-image executables.
* Introduce `ExecutableSpec` extension, for projects that publish executables to configure how those executables should be published.
* `./griddles buildNative`, by default, will only build the executable of the host OS/Arch, and will no longer cross-build.
* The target arch of `./gradlew buildNative` can be changed using `-Dpkl.targetArch=<aarch64|amd64>`.
* On linux/amd64 only, with `./gradlew buildNative`, a statically linked executable can be built using `-Dpkl.musl=true`
* Make `javaExecutable` a dependency of `assemble`
* Make `testStartJavaExecutable` a dependency of `check`
* Change name `pklNativeBuild` to `pklNativeLifecycle` to better match the plugin's purpose
* Remove Truffle SVM classes from main source set (don't publish these classes as part of the pkl-cli JAR)
* Change CircleCI definition to publish new executables
* Change CircleCI definition to call `buildNative` instead of individual task names
This bumps Clikt from version 3 to version 5, which, among other things, improves
the help text formatting with colors.
Also:
* Add `--version` flag to pkldoc, pkl-codegen-java, pkl-codegen-kotlin
* Add help text to pkldoc, pkl-codegen-java, pkl-codegen-kotlin
When we updated spotless's Java and Kotlin formatter, we changed the underlying
formatting rules.
However, due to spotless ratcheting, these formatting changes don't get applied unless a file
gets touched in a commit.
To avoid future PRs introducing lines of change that aren't related to the intention of the PR,
this is a one-time format of all files.
This updates the GraalVM and Truffle libraries to 2024.1.2.
This also updates the build logic to compile Java sources using Java 21, due to some compile-only dependencies within GraalVM/Truffle using class file version 65. However, the produced artifact is still compatible with Java 17.
This also changes the Gradle build logic to use toolchains, and to test the Java libraries with JDK 17 and 21.
One consequence of this change is that Truffle is no longer shaded within the fat jars.
feat: support for jvm21+ toolchain
feat: support for gradle toolchains
feat: pass -PnativeArch=native to build with -march=native
test: multi-jdk testing support
test: support for jvm-test-suite plugin
test: add tasks to run jpkl eval on multiple jdks
test: make jdk exec tests respect multi-jdk flags and ranges
fix: remove mrjar classes at >jvm17 from fatjars
fix: use jdk21 to run the tests (needed for Unsafe.ensureInitialized)
fix: truffle svm dependency is required after graalvm 24.0.0
fix: warnings for gvm flag usage, renamed truffle svm macro
fix: build with --add-modules=jdk.unsupported where needed
fix: don't use gu tool for modern graalvm versions
fix: catch Throwable instead of deprecated-for-removal ThreadDeath
chore: buildinfo changes for JVM targets, toolchains
chore: enforce testing at exactly jdk21
chore: enforce build tooling at jdk21+
chore: bump graalvm/truffle libs → 24.1.2
chore: toolchains for buildSrc
Signed-off-by: Sam Gammon <sam@elide.dev>
- update Kotlin from 1.7.10 to 2.0.21
- Kotlin 1.6 dependencies in Gradle lock files are expected because kotlinc,
which is also used by some tests, internally uses some 1.6 dependencies
for backwards compatibility reasons.
- update kotlinx-html and kotlinx-serialization
- adapt Kotlin code where necessary
- use Kotlin stdlib Path APIs where possible
- fix IntelliJ Kotlin inspection warnings
- reformat code with `./gradlew spotlessApply`
- ktfmt adds lots of trailing commas
- Add workaround to fix IntelliJ "unresolved reference" errors
Any thrown Pkl Errors are colored in the simple test report!
Also:
* Refactor `TextFormatter` to be more generic; rename to `TextFormattingStringBuilder`
* Adjust test report slightly (no emojis, add more spacing).
* Introduce `ColorTheme` class.
* Make stack frame descriptors colored as "faint"
Also: this changes the summary so it summarizes _all_ modules, rather than a summary per module.
---------
Co-authored-by: Islon Scherer <islonscherer@gmail.com>
Co-authored-by: Philip K.F. Hölzenspies <holzensp@gmail.com>
GraalVM for JDK 17.0.12 is the final Critical Patch Update
made available under the GraalVM Free Terms and Conditions license.
Subsequent Critical Patch Updates require a commercial license.
- keep implementation classes internal to their packages
- make classes final if possible
- make namespace classes non-instantiable
- throw IllegalStateException instead of ExternalReaderProcessException for use after close
- common convention already used by HttpClient etc.
- programming errors should be signaled with unchecked exceptions
- use private instead of public lock object
- polish Javadoc
- delete commented out code
- don't use star import for a single class
Changes:
* Move class `TestResults` to package `org.pkl.core`, because it is a public class (it's the result of `Evaluator#evaluateTest`)
* Change examples to treat individual examples as assertions in the same test. Previously, they were considered different tests with an incrementing number. This better aligns with how facts are treated.
* Change `TestResults` to be a record, and introduce builders.
* Remove "module" test result section (it is not really a section).
* Add javadoc to `TestResults`
* Formatting fix: prefix ✍️ emoji just like we do the ❌ and ✅ emojis
* Consider writing examples as failures, not successes. `pkl test` will exit with code 10 if the only failing tests are due to writing examples.
This adds a new feature, which allows Pkl to read resources and modules from external processes.
Follows the design laid out in SPICE-0009.
Also, this moves most of the messaging API into pkl-core
- Update dependencies by deleting lock files and regenerating them with `gw updateDependencyLocks`.
Deleting lock files avoids strange `some.library:some.older.version=default` entries.
Most updated dependencies are test dependencies.
- Handle breaking changes in library commonmark.
- Fix test to close PackageServer exactly once.
This problem surfaced because JUnit 5.11 changed override rules for lifecycle methods,
resulting in too many instead of too few close() calls.
- Bump msgpack version
- Bump clikt version
- Bump Gradle plugin versions
To make error messages from Pkl eval easier to read, this change uses
the Jansi library to colour the output, making it quicker and easier to
scan error messages and understand what's happened.
The Jansi library also detects if the CLI output is a terminal capable
of handling colours, and will automatically strip out escape codes if
the output won't support them (e.g. piping the output somewhere else).
This addresses an issue where network requests may fail if cert revocation checks
error, which may occur due to availability issues, or due to lack of internet access.
Revocation checking can still be enabled by setting JVM property com.sun.net.ssl.checkRevocation if on the JVM.
Also:
* Load built-in certs from resources, and move them to pkl-commons-cli
* Fix an issue where HttpInitException is not caught when loading a module
Rationale: "proxy" can mean very different things (e.g. java.lang.reflect.Proxy in Java).
This makes the flag name more specific.
CLI:
* `--proxy` -> `--http-proxy`
* `--no-proxy` -> `--http-no-proxy`
Gradle:
* `proxyAddress` -> `httpProxy`
* `noProxy` -> `httpNoProxy`
This fixes an issue where an error coming from loading a project file is shown as a PklBugException.
There were two problems here:
1. proxyAddress needs to be a lazy value, because it can try to load a PklProject
2. accessing proxyAddress can throw a PklException, so it needs to be within the try/catch
Instead of bundling Pkl's built-in CA certificates as a class path resource and loading them at runtime,
pass them to the native image compiler as the default SSL context's trust store.
This results in faster SSL initialization and is more consistent with how default certificates
are handled when running on the JVM.
Further related improvements:
- Remove HttpClientBuilder methods `addDefaultCliCertificates` and `addBuiltInCertificates`.
- Remove pkl-certs subproject and the optional dependencies on it.
- Move `PklCARoots.pem` to `pkl-cli/src/certs`.
- Fix certificate related error messages that were missing an argument.
- Prevent PklBugException if initialization of `CliBaseOptions.httpClient` fails.
- Add ability to set CA certificates as a byte array
- Add CA certificates option to message passing API
* Add `--proxy` and `--no-proxy` CLI flags
* Add property `http` to `pkl:settings`
* Move `EvaluatorSettings` from `pkl:Project` to its own module and add property `http`
* Add support for proxying in server mode, and through Gradle
* Add `setProxy()` to `HttpClient`
* Add documentation
This adds support for Windows.
The in-language path separator is still `/`, to ensure Pkl programs are cross-platform.
Log lines are written using CRLF endings on Windows.
Modules that are combined with `--module-output-separator` uses LF endings to ensure
consistent rendering across platforms.
`jpkl` does not work on Windows as a direct executable.
However, it can work with `java -jar jpkl`.
Additional details:
* Adjust git settings for Windows
* Add native executable for pkl cli
* Add jdk17 windows Gradle check in CI
* Adjust CI test reports to be staged within Gradle rather than by shell script.
* Fix: encode more characters that are not safe Windows paths
* Skip running tests involving symbolic links on Windows (these require administrator privileges to run).
* Introduce custom implementation of `IoUtils.relativize`
* Allow Gradle to initialize ExecutableJar `Property` values
* Add Gradle flag to enable remote JVM debugging
Co-authored-by: Philip K.F. Hölzenspies <holzensp@gmail.com>
GenericUrl is a catch-all that uses URL.openConnection().
Since we now have special handling of HTTP urls, it makes more sense to
put it in its own module key.
