codegen-java:
- use `pattern.pattern()` instead of `pattern` in hashCode method
(consistent with equals method)
codegen-kotlin:
- use `regex.pattern` instead of `regex` in hashCode method
(consistent with equals method)
- if a data class has a Regex property, generate not only
an equals method but also a hashCode method
Motivation:
codegen-kotlin generates a mix of data classes and regular classes.
For regular classes, toString() methods are also generated.
However, the output of generated toString() methods
differs from the output of default toString() methods of data classes.
Changes:
Generate toString() methods that produce the same output
as default toString() methods of data classes.
Also: rename KotlinCodegenOptions to KotlinCodeGeneratorOptions
The new name is consistent with existing names KotlinCodeGenerator and CliKotlinCodeGeneratorOptions.
Backward compatibility is ensured by turning KotlinCodegenOptions into a (deprecated) type alias.
Motivation:
In Spring Boot 3.0, the annotation type `org.springframework.boot.context.properties.ConstructorBinding`
was deprecated in favor of `org.springframework.boot.context.properties.bind.ConstructorBinding`.
In 3.2, the old annotation type was removed.
As of 3.0, a `@ConstructorBinding` annotation is no longer required/recommended for configuration classes with a single public constructor.
Changes:
Remove generation of `@ConstructorBinding` annotations in codegen-java and codegen-kotlin.
Result:
- Generated code is compatible with Spring Boot 3.x.
(Verified with locally updated pkl-spring.)
- Generated code is no longer compatible with Spring Boot 2.x.
To use Pkl 0.27 and later with Spring Boot 2.x, use Pkl 0.26's code generator.
- Fixes#139.
Motivation:
- Java serialization makes as much sense for module classes as it does for regular classes.
- Offer same Java serialization support as codegen-java.
Changes:
- Move generation of `appendProperty` method and serialization code
into new method `generateCompanionRelatedCode`.
- Improve/fix generation of serialization code.
Result:
Java serialization is also supported for module classes.
* codegen-kotlin: Don't generate equals/hashCode/toString/copy/:Serializable for abstract classes
* Polish KotlinCodeGeneratorTest
- use `assertContains()` instead of `assertThat().contains()`
- remove redundant `trimIndent()` and `trimMargin()` calls
- rename `javaCode` to `kotlinCode`
* Overhaul KotlinCodeGeneratorTest
- introduce classes KotlinSourceCode and KotlinSourceCodeAssert
- change assertions to use KotlinSourceCodeAssert via `assertThat(kotlinCode)`
- use explicit trimIndent() and trimMargin() for multiline string literals
- IntelliJ editor desperately wants to insert trimIndent()
- can be used by kotlinc and ktfmt
- format code in the exact way it falls out of the IntelliJ editor
(successfully destroyed by ktfmt)
Adds a `rename` field to the Java/Kotlin code generators that allows renaming packages and classes during codegen.
* Add `--rename` flag to CLIs
* Add `rename` property to Gradle API
This changes the file paths to use characters that are safe for Windows.
Channges the output of the following:
* Package cache directory
* Generated pkl-doc files
* Kotlin generated code
Unsafe characters are encoded as (<hex>).
For example, the colon character `:` is encoded as `(3a)`.
Additionally, this changes the cache directory prefix (package-1 to
package-2).
Follows the design of https://github.com/apple/pkl-evolution/pull/3
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.
