Checks, validates and/or modifies asset contents. An AssetProcessor is usually provided as a separate dependency.

Start by adding the dependency to your pom.xml:

  <dependency>
    <groupId>org.jooby</groupId>
    <artifactId>jooby-assets-my-processor</artifactId>
    <scope>provided</scope>
  </dependency>

Notice the provided scope. The processor is only required for development, since the assets are processed at runtime in this case. In prod, assets are processed at build-time via the Maven or Gradle plugins, so the dependency is not needed there. This also helps to keep the number of dependencies and the jar size smaller.

After the dependency is declared, all that's needed is to add the processor to the pipeline:

assets {
  pipeline: {
    dev: [my-processor]
  }
}

It's possible to configure or set options as well:

assets {
  pipeline: {
    dev: [my-processor]
    dist: [my-processor]
  }
  my-processor {
    foo: bar
  }
}

The previous example sets the foo property to bar. Options can be set per environment as well:

assets {
  pipeline: {
    dev: [my-processor]
    dist: [my-processor]
  }
  my-processor {
    dev {
      bar: bar
    }
    dist {
      foo: bar
    }
    foo: foo
  }
}

In this example, the processor will have two properties in the dev environment: foo:foo and bar:bar, while in dist the processor will only have foo:bar

The my-processor token will be resolved to the: org.jooby.assets.MyProcessor class. The processor name is converted to MyProcessor by converting the hyphenated name to upper camel case and by placing it in the org.jooby.assets package (a default for processors).

A custom binding is provided via the class property:

assets {
  pipeline: {
    dev: [my-processor]
    dist: [my-processor]
  }
  my-processor {
    class: whatever.i.Want
  }
}

Contributes new or dynamically generated content to a fileset. Content generated by an aggregator might be processed by an {@link AssetProcessor}.

Start by adding the dependency to your pom.xml:

<dependency>
    <groupId>org.jooby</groupId>
    <artifactId>jooby-assets-dr-svg-sprites</artifactId>
    <scope>provided</scope>
  </dependency>

Notice the provided scope. The aggregator is only required for development, since the assets are processed at runtime in this case. In prod, assets are processed at build-time via the Maven or Gradle plugins, so the dependency is not needed there. This also helps to keep the number of dependencies and the jar size smaller.

After the dependency is declared, all that's needed is to add the svg-sprites aggregator to a fileset:

assets {
  fileset {

    home: [
      // 1) Add the aggregator to a fileset
      svg-sprites,
      css/style.css,
      js/app.js
    ]
  }

  svg-sprites {
    // 2) The `css/sprite.css` file is part of the `home` fileset.
    spritePath: "css/sprite.css"
    spriteElementPath: "images/svg",
  }

}

In this example, the svg-sprites aggregator contributes the css/sprite.css file to the home fileset. The fileset then looks like:

assets {
  fileset {
    home: [
      css/sprite.css,
      css/style.css,
      js/app.js
    ]
  }
}

It replaces the aggregator name with one or more files from the AssetAggregator.fileset method.

{{available-asset-procesors.md}}