The maven publish plugin isn't setting up dependencies correctly,
and we are getting errors like:
"Task ':pkl-config-java:publishFatJarPublicationToMavenLocal' uses
this output of task ':pkl-config-java:signLibraryPublication' without
declaring an explicit or implicit dependency."
This adds a workaround for this type of error.
Changes the packager to exclude any empty directories.
This change means that pkl project package for an already published packages will fail. The packager checks for an existing package at this version, and compares checksums. It will then error if the checksum has changed.
This is technically a breaking change, albeit a minor one. The workaround is to publish new versions of packages.
Published packages should still be compatible with Pkl 0.25.
Make sure that declaring a dependency on project `pkl-commons-test`
suffices to have its test fixtures generated.
This fix should work reliably.
However, there may be a more idiomatic way to achieve the same result.
- Fix and clean up the pkl-commons-test build script.
- Change tests to read test packages/certs directly from
the file system instead of packaging and reading them
from the class path.
- Update expected checksums of some test packages.
- Fix a conflict between Pkl's and Gradle's
Kotlin libraries in the pkl-gradle project.
- Fix build deprecation warnings.
- Ensure Gradle distribution integrity with `distributionSha256Sum`.
- Manually verify integrity of Gradle wrapper added by this commit.
This fixes an assertion error that gets thrown if:
1. A module declares a class as abstract
2. An amending module does not use that abstract class as a type
Underneath the hood, the modifiers of the class/typelias object member
is considered different from the modifiers on the VmClass/VmTypeAlias
values.
The object model skips forcing any explicitly members that are explicitly
declared hidden, abstract, or local.
However, it _should_ evaluate any abstract classes found in a module.
So, it's incorrect to apply the same modifiers on the class to the object member.
This is a comprehensive solution to the "flaky PackageServer tests"
problem. It rules out port conflicts and imposes no limits on test
parallelism. The same solution can be used for other test servers
in the future.
Major changes:
- Turn `PackageServer` from a singleton into a class that is
instantiated per test class or test method.
- Start the server the first time its `port` property is read.
Bind the server to an ephemeral port instead of port 12110.
- For every test that uses `PackageServer`, pass the server port to
`--test-port`, `HttpClient.Builder.setTestPort`, the `CliBaseOptions`
or `ExecutorOptions` constructor, or the Gradle plugin's `testPort` property.
Wire all of these to `RequestRewritingClient`'s `testPort` constructor parameter.
- Enhance `RequestRewritingClient` to replace port 12110 with `testPort`
in request URIs unless `testPort` is -1 (its default).
- Introduce `ExecutorOptions.Builder`.
This makes executor options more comfortable to create
and allows to hide options such as `testPort`.
- Deprecate the `ExecutorOptions` constructor to steer users towards the builder.
- Get rid of `ExecutorOptions2`, which is no longer needed.
- Clean up `EmbeddedExecutorTest` with the help of the builder.
* pkl-excutor tests: symlink 0.25.0 distribution into pkl-executable/build
* Use `IoUtils.getPklHomeDir` in HttpClientBuilder
* Simplify Exceptions.java
* Enable testing for older pkl-executor distribution
Moving to java.net.http.HttpClient brings many benefits, including
HTTP/2 support and the ability to make asynchronous requests.
Major additions and changes:
- Introduce a lightweight org.pkl.core.http.HttpClient API.
This keeps some flexibility and allows to enforce behavior
such as setting the User-Agent header.
- Provide an implementation that delegates to java.net.http.HttpClient.
- Use HttpClient for all HTTP(s) requests across the codebase.
This required adding an HttpClient parameter to constructors and
factory methods of multiple classes, some of which are public APIs.
- Manage CA certificates per HTTP client instead of per JVM.
This makes it unnecessary to set JVM-wide system/security properties
and default SSLSocketFactory's.
- Add executor v2 options to the executor SPI
- Add pkl-certs as a new artifact, and remove certs from pkl-commons-cli artifact
Each HTTP client maintains its own connection pool and SSLContext.
For efficiency reasons, It's best to reuse clients whenever feasible.
To avoid memory leaks, clients are not stored in static fields.
HTTP clients are expensive to create. For this reason,
EvaluatorBuilder defaults to a "lazy" client that creates the underlying
java.net.http.HttpClient on the first send (which may never happen).
This reverts commit 7f404fff49.
The package is derived from the module name.
Having `module com.example.Foo` in Pkl
will create Kotlin `package com.example`.
Eventually, we may want to introduce a way to map
Pkl names to package names that provides finer
controls to the code generator.
When I delete pkl-core/src/test/files/LanguageSnippetTests/output and
run "gw test", most output files are regenerated, but 46 of them aren't.
I assume these are stale files that should be deleted.
- fix: make version catalog accessible from `buildSrc` plugins
- chore: declare `googleFormatVersion` in version catalog
- chore: declare `ktfmt` in version catalog
Relates-To: apple/pkl#204
Signed-off-by: Sam Gammon <sam@elide.ventures>
This change activates the `TYPESAFE_PROJECT_ACCESSORS` feature
preview in Gradle, and switches to such accessors instead of
string-based project references, where possible
Relates-To: apple/pkl#204
Signed-off-by: Sam Gammon <sam@elide.ventures>
This small change fixes a bug introduced by the `validatePom` task
within the `pklPublishLibrary` plugin. When running project-wide
tasks like `./gradle tasks`, projects which don't provide a POM
fail the build, because the `generatePomFileForLibraryPublication`
cannot be found, but it is expected to be present.
Fixes and closesapple/pkl#215
Signed-off-by: Sam Gammon <sam@elide.ventures>
