- About XNAT
- News & Events
- XNAT Marketplace
- Contact Us
Despite remaining fairly recognizable in the front end, XNAT 1.7 has changed quite a bit under the hood. Here is a quick overview of the new features.
Completely overhauled, war-only installation process
The XNAT installation process no longer requires the xnat_builder, and there is no need to run setup or update scripts. In place of the builder, XNAT uses a Gradle plugin to generate code from data-type schema files. The XNAT application is now delivered as a .war file, which can be dropped right into your Tomcat 7 server. There is no source code or folder to worry about.
Additionally, since the database schema generation and updates are managed on the fly, which will make it far easier to upgrade XNAT in the future.
Also, by using Vagrant and VirtualBox, you can have a development version of XNAT running in a virtual machine. The process literally takes just a few minutes, and works on all major platforms.
In previous instances of XNAT, administrators had to wrangle a bunch of settings in properties files during the installation process. This meant that these settings were either manually duplicated or unavailable in the Administration UI once the application was built. In XNAT 1.7, we have radically reduced the amount of properties that must be set prior to installation*, and moved a core set of first-time-settings into a setup screen that displays in the UI on your first launch. Each of these settings is persisted in the database and can be revisited later via the UI as needed.
(* Exception: The PostgreSQL and Hibernate database connection strings must be set in an xnat-conf.properties file. But that's it, really!)
The Admin UI has also received a major overhaul in appearance and usability, as we attempt to lower the barriers to entry for first-time users. The rendering of the UI uses a new XNAT Spawner library for form elements, which will be more widely deployed throughout the XNAT application in subsequent releases.
XNAT 1.6 Modules are not compatible with XNAT 1.7. These and other customizations will need to be refactored to comply with the XNAT 1.7 plugin structure.
Modules were introduced with some fanfare in XNAT 1.6. However, this implementation was one-way only: once a module was added to a running instance of XNAT, it could not be removed without significant effort.
XNAT 1.7 has a true plugin architecture, where extensions to XNAT are treated as separate projects by the application. Data types and new functionality can be added via plugin now, and each plugin can generate custom administration functions in the rebuilt Admin UI.
New XAPI functions have been added to XNAT in parallel to the existing REST API, which still functions as before. The benefit of the new XAPI functions is that they are discoverable and self-documenting within the Admin UI using the Swagger tool. This allows you to browse and execute XAPI commands right in your browser, which can be an immensely valuable tool during script development and testing.
As we demoed in the XNAT Workshop, it will be possible to link XNAT to a Docker Container and perform processing on a Docker Image. This feature is still in development, and is still in pre-beta, but is very exciting.
See: Getting Started
XNAT 1.7 offers nascent support for UI theme development and deployment. This feature offers a new way to create and manage UI customizations and tailor those customizations to specific user roles.
The XSync Plugin is being developed for XNAT 1.7, which will allow administrators and project owners to sync their data to a remote XNAT, essentially streamlining one of the major use cases of the JAAT tool.
The underlying architecture for 1.7 is mostly the same as 1.6: