The bundle name is now optional. By default, the name of the file (without extension) will be used as a bundle name

Both asset type and name are now optional. They are deducted from the first location found

Added lots of new checks for consistency of bundles

Added a new bundle.location config option, mainly used for testing purpose, allowing to tell bundle loaders to load JSON files from a specific folder

Generally speaking, formatting and consistency errors are now buffered before being flushed in a DandelionException.

Bundle definitions (whether XML or JSON) are now checked just after they are parsed (consistency, required configuration)

The StandardConfigurationLoader has been updated in order to be able to load different properties files depending on the active profile

A profile is activated using the -Ddandelion.profile.active system property

Some reserved words are used to load preconfigured sets of configurations

Any custom profile name can be used. All options that are not specified in the corresponding properties file will default to dev values

Plenty of configuration points have been renamed or added (toolAssetPrettyPrintingEnabled, toolBundleGraphEnabled, assetCachingEnabled, …​) for more consistency

Added support for JBoss VFS2/VFS3 ensuring compatibility with JBoss AS 5+ / WildFly servers

Added support for Websphere Application Server

An AssetVersioningStrategy can be configured within the configuration

2 built-in implementations are provided: ContentAssetVersioningStrategy (for fingerprinting) and FixedAssetVersioningStrategy

asset.versioning.mode ASSET_VERSIONING to enable automatic asset versioning

asset.versioning.strategy:to select a particular strategy

asset.fixed.version.type: to select the FixedVersionType if the FixedAssetVersioningStrategy is selected

asset.fixed.version.value: to pass a value to the NUMBER and DATE version types

asset.fixed.version.datepattern to configure the version if the version type is set to DATE

Added new strategy allowing to load XML file using a validating SAX parser

All loaders have been updated to be able to apply 2 loading strategy sequentially : first by scanning for bundles in JSON, then XML

New handlers are now in charge of a specific task: injecting the requested assets (main feature), displaying the debugger, reloading the bundles, clear the cache store, clear the asset storage, etc…​

All handlers are assembled, using their rank, into two chains: a pre-handler chain (in charge of pre-processing requests) and a post-handler chain (in charge of post-processing responses)

Added support for GZIP compression via a new request handler. Enabled thanks to a new tool.gzip configuration option. By default, the GZIP compression is done on several text-based mime types: text/html, text/css, application/x-javascript, application/javascript, text/javascript, text/plain, text/xml, application/xhtml+xml, image/svg+xml

Each handler can decide to stop the chain (usage example: when the value of the If-None-Match header equals the value of the ETag header: no need to go further)

Custom handlers can be added thanks to the new SPI: com.github.dandelion.core.web.handler.RequestHandler

The debugger has been fully refactored and now contains multiple pages (asset, options)

Old graph viewer (and all related stuff) have been removed

The bundle graph viewer is now accessible with the "ddl-debug" URL parameter (previously "showGraph")

The bundle reloading is now performed with the "ddl-reload" URL parameter (previously "bundleReload")

Added new debug page allowing to visualize the asset storage, the caching system, …​

Cache headers are now set by a dedicated request handler which is part of the filter chain

Asset caching and gzipping disabled in dev profile

Make a mecanism of Asset generator based on a AssetContent and a AssetContentGenerator.

Built-in generator

The generated Javascript code is now pretty printed by default when in dev profile, using JS Beautifier

a new debug page that displays all alerts for the current request and suggestions if applicable

a new post-filtering handler which performs the check for each request and can report in multiple ways

Added a new tool.alert.reporting config option in order to enable/disable alert reporting

Reporting type can be configured thanks to a new tool.alert.reporting.mode config option (console, notification, none or all)

Added a new components.standalone config option used to mark components as standalone. In this case, the corresponding loader will only scan for regular bundles (not vendor ones)

JavaScript processing is made using customized Thymeleaf template engine

Added a new template mode "DANDELION-JS" (and all related classes: template resolver, template parser, template writer) allowing to process Javascript assets with Thymeleaf expressions

Only "user assets" are concerned, not vendor ones

For all "user assets", the final location now contains a request key (also based on a MD5 hash) as follows: "/servletUrlPattern/requestKey/cacheKey/assetType/assetName-assetVersion.assetType" (should be cleaned for CSS)

Only for concerned "user-assets" (JS), server & browser caching are disabled thanks to HTTP headers

All attributes from the original request (the one which serves the view) are wrapped in a new RequestData object and stored in a basic cache, whose data expire after 30s from their instanciation

Added a new asset.js.processing config option to enable/disable Thymeleaf processing of external js assets (enabled by default)

Added new handlers in charge of feeding/clearing session with/from flash data

Asset final locations can now contain one more MD5 hash corresponding to the request key, used to lookup in the attribute stored in session

The cache is only initialized if Thymeleaf is present in the classpath, in which case JavaScript assets may be processed

The cache is initialized with a max capacity of 100 entries