2.1.1

• Fix double escape of content blocks in HTML attributes introduced with 2.1.0

2.1.0

Caution: There is an output escaping bug in this release (content blocks in HTML attributes are escaped twice). Please skip this version and upgrade to 2.1.1 or later.

• #161 Unsafe can only be used for rendering strings

2.0.4

• #156 Fix ResourceCodeResolver lookup for templates in the root of resources
• #159 mark sourceDirectory and targetDirectory as required for maven precompile
• #152 remove readonly=true from maven plugin parameters
• Create required directories for generated binary static content resources

2.0.3

• #128 throw exception for self contained jars without precompiled templates
• #149 Fix execution optimizations have been disabled warning in gradle plugin
• #151 Fix escaping of js comments on same line
• Bump kotlin version to 1.6.21 (jte-kotlin only)
• Adjust JSP converter for less strict jte 2 template structure

2.0.2

• #144 spring boot starter contribution by @atomfrede
• Attribute map values in html intercepter are properly escaped
• Remove onHtmlAttributeStarted from HtmlInterceptor

2.0.1

• Fix escaping issue with content blocks containing HTML attribute output in localizer params.
• Old template is removed from template cache before hot reload, so that compilation errors are reproducible.

2.0.0

Features

• #126 The specialized @tag and @layout keywords have been removed in favor of @template. This change allows to structure template files freely. Templates can now live close to the place where they are used. For example:
  • Create high level module directories that contain all templates and are not scattered in tag/layout directories
  • Split a large page in smaller templates that live next to that page
• #125 Added @raw keyword for output that is unprocessed by jte
• #122 Faster directory watcher on MacOS

Migration Guide

#126 is a breaking change, the old @tag/@layout is no longer supported. If jte 2 finds those keywords during compilation it will fail and output instructions how to migrate your project automatically.

How to upgrade:

• Bump jte dependency to the latest 2.x release
• Compile your templates (either through maven, gradle or by simply opening your website locally)
• In case you use any of the removed keywords, the compiler will fail and output a Java class that does the migration
• Create a class with the migration code in your project and run the main method
• Make sure to upgrade the IntelliJ plugin to 2.x

Migration class, in case you want to migrate right away without the compile step:

public class Migration {
    public static void main(String[] args) {
        gg.jte.migrate.MigrateV1To2.migrateTemplates(java.nio.file.Paths.get("your jte source root directory"));
    }
}

IntelliJ plugin features

You also want to make sure to use the latest IntelliJ plugin to get support for the new syntax.

• Support for @template keyword
• Support for @raw keyword
• Move template file refactoring is working now

IntelliJ can no longer guess the jte root directory by moving up the directory tree until a tag/layout directory is found. You will need to create a .jteroot file within the root directory to help the plugin here (the plugin will complain if this file doesn't exist).

1.12.1

• Add support for kebab-case directory names
• Use Gradle 7.3 to support building with Java 17
• Improved error handling of unclosed or not matching braces

1.12.0

Features

• Drastically improved hot reload speed. Now, only changed classes are recompiled. This results in huge speedups during development, when deep template hierarchies are adjusted and hot reloaded.
• Fixed a bug that tags shared between multiple templates were only hot reloaded for one template.
• Removed side effects from DirectoryCodeResolver

Breaking changes

To improve hot reloading, changes had to be made to the CodeResolver interface.

In case you use one of the supplied implementations DirectoryCodeResolver or ResourceCodeResolver, no changes are required.

In case you have your own CodeResolver implementation, you need to make the following adjustments:

• boolean hasChanged(String name); was removed from the interface, you will need to delete this method from your implementation.
• long getLastModified(String name); was added to the interface, you will need to implement this method:
  • In case your previous method always returned false, simply return 0L.
  • Otherwise, you need to return the last modified timestamp in milliseconds. For example, if you'd use the File API, that would be File::lastModified().

1.11.4

• #113 curly braces do not break the parser