Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.

Despite remaining fairly recognizeable 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,




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. 

See: Installing XNAT 1.7

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.

See: Running XNAT with Vagrant 

Consolidated configurations, easy browser-based setup and overhauled Admin UI

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 file. But that's it, really!)

See: XNAT Setup - First Time Configuration

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. 

Modules have been replaced by a new Plugin architecture


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. 

See: Deploying Plugins in XNAT 1.7

New, self-documenting REST API using Swagger

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. 

Support for new features in development

Support for Automation


Support for Container Services


Support for Themes


Support for XNAT-to-XNAT project data sync


What Hasn't Changed in XNAT 1.7? 

The underlying architecture for 1.7 is mostly the same as 1.6:

  • All of the data types are the same
  • Security and user data are the same
  • Most existing configuration data will migrate quietly