# asset processor

Checks, validates and/or modifies asset contents. An [AssetProcessor]({{defdocs}}/assets/AssetProcessor.html) is usually provided as a separate dependency.

## usage

Start by adding the dependency to your ```pom.xml```:

```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:


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

## configuration

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

```text
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:

```text
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```

## binding

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:

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

# asset aggregator

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

## usage

Start by adding the dependency to your ```pom.xml```:

```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]({{defdocs}}/assets/AssetAggregator.html#fileset--) method.

# available processors

{{available-asset-procesors.md}}
