Trellis 0.9 series released

[Aaron Coburn]

I am happy to announce that the 0.9 series of TrellisLDP was published last week and is now available. A big thanks to everyone who contributed to this release.

Docker containers can be downloaded from Docker Hub. Alternatively, a deployable application can be downloaded directly from the Trellis website. All individual Java artifacts are available from Maven Central.

Now that we have made it to the 0.9.x series, the release cadence will likely pick up again. In fact, the current release is already 0.9.3, but please check either the Trellis website or the Github repository to find the latest release.

Changes and new features

This release represents a significant amount of work over the last year, so I will highlight only a few of the changes.

1. Microprofile. The codebase has fully embraced Microprofile, which can be thought of as the next generation of Java enterprise development. This gives us flexibility to use different underlying implementations (e.g. TomEE or OpenLiberty) though we have chosen Quarkus as a target; Quarkus is extremely well supported and provides great tooling for both development and operations. Trellis continues to support the existing Dropwizard deployment environment, though the primary focus going forward will center on Microprofile.

2. LDP Container behavior. In the past, LDP resources did not have a trailing slash. Now, as per the LDP best practices document and on the advice of many LDP experts, Containers now will end in a trailing slash. Requests for a container without a trailing slash will simply be redirected to the canonical version. This change does not involve any data migration

3. Digests are gone. There are a lot of problems with exposing a digest endpoint on a public web server, and so this feature has been removed from Trellis.

4. LDP type triples are now included in responses. In the past, all LDP type data was contained in Link headers, but it is often useful to have this information in the body of an RDF response. This can be turned off by configuration, but the default is now to include that information.

5. PATCH operations can now be used to create resources. It has always been the case that PATCH could be used to create ACL resources, but now it is also possible to create ordinary LDP resources with PATCH.

6. Extension modules. First, the version number of the extension modules have been aligned with the core Trellis code, so everything is now in the 0.9.x series. Secondly, the extension modules now also contain a Cassandra-based persistence layer.

Upgrading

If you have been using Trellis in the past and plan to continue to use the Dropwizard-based artifacts, there will be no changes to the underlying data model or configuration.

If you wish to start using the Quarkus-based database artifacts, the initial data migration does not happen automatically, so you will need to set the following environment variable the first time you start up the application: QUARKUS_FLYWAY_MIGRATE_AT_START=true. For all subsequent start-up events, that variable will not be needed. If your database already contains data, you will also need to include the following environment variable QUARKUS_FLYWAY_BASELINE_ON_MIGRATE=true. No user data will be touched, though it is always good practice to backup a database before performing these migrations. This and other database configuration information is described at https://github.com/trellis-ldp/trellis-extensions

Documentation

The documentation is a work in progress, especially for the Quarkus-based environments. The Dropwizard app documentation can be found at https://github.com/trellis-ldp/trellis/wiki/App-Configuration-Guide

A complete list of Quarkus-based configuration can be found at https://quarkus.io/guides/all-config

If you have questions or encounter issues with the software, feel free to open a discussion thread on this list or an issue on the Trellis Github repository.

Best regards,

Aaron