Less pre-processing with Maven and Jetty

Continuing on from the previous post we will set up a pre-processor for .less files that will continue to process file changes for Jetty to pick up. Regardless of the Java web framework you are using the file layout generally looks similar to the following.

src/
   main/
      java/
      less/
      webapp/
         js/
         css/
         index.html

Jetty will pick up and changes to files made under the webapp directory so we want our less pre-processor to monitor files in the less/ directory put the compiled css files into the css/ directory where Jetty will pick them up.

The standard less compiler is actually written in JavaScript and is available as a Node NPM module. There is also a watch-less NPM module that will monitor files and run the less compiler when changes are detected. To use node modules we will use the frontend-maven-plugin.

<plugin>
    <groupId>com.github.eirslett</groupId>
    <artifactId>frontend-maven-plugin</artifactId>
    <version>0.0.29</version>

    <configuration>
        <nodeVersion>v0.11.14</nodeVersion>
        <npmVersion>2.13.4</npmVersion>
        <installDirectory>.</installDirectory>
        <workingDirectory>.</workingDirectory>
    </configuration>

    <executions>
        <execution>
            <id>install node and npm</id>
            <goals>
                <goal>install-node-and-npm</goal>
            </goals>
        </execution>

        <execution>
            <id>npm install</id>
            <goals>
                <goal>npm</goal>
            </goals>
            <configuration>
                <arguments>install</arguments>
            </configuration>
        </execution>
    </executions>
</plugin>

This will install Node and NPM and then install all NPM modules defined in the package.json file in the root of our project.

{
  "dependencies": {
    "watch-less": "emmostrom/watch-less"
  }
}

This is a version of watch-less I have modified to watch std-in and to have an option to just run once and not monitor files. Now we can modify our groovy plugin code from the previous post to build a process for our watch-less program.

if (isJettyRun) {
  new ProcessBuilder(
    ["node/node", "node_modules/watch-less/cli.js", 
     "-d", "src/main/less/app", 
     "-r", "src/main/webapp/css", 
     "-e", ".css", 
     "--watch-stdin"]
  ).inheritIO().directory(project.getBasedir()).start()                             
} else {
  def proc = new ProcessBuilder(
    ["node/node", "node_modules/watch-less/cli.js", 
     "-d", "src/main/less/app", 
     "-r", "src/main/webapp/css", 
     "-e", ".css", 
     "--once"]
  ).redirectErrorStream(true).directory(project.getBasedir()).start()
  proc.waitForOrKill(15000)
  proc.in.eachLine { line -> println line }
}

Live pre-processing with Maven and Jetty

Running

mvn jetty:run

works well for development as Jetty will reload your web app files (js, css, html, ...) when they change without needing to restart. However handling files that need pre-processed first like .less files is a little more difficult since Jetty can't detect that a specific process in Maven needs re-run.

One solution is to use an external tool to do the pre-processing. As long as the external tool has a file watcher option we can leave it running in the background and then stop it when Maven stops.

<plugin>
<groupId>org.codehaus.groovy.maven</groupId>
<artifactId>gmaven-plugin</artifactId>
<executions>
    <execution>
        <phase>process-resources</phase>
        <goals>
            <goal>execute</goal>
        </goals>
        <configuration>
            <source><![CDATA[
            /*
             * If running in Jetty - pre-process when they change
             * Otherwise just run once
             */
            boolean isJettyRun = false
            List<String> goals = session.getGoals()
            for (String s : goals)
                if (s.equals('jetty:run'))
                    isJettyRun = true

            if (isJettyRun) {
                new ProcessBuilder(["external_app", "--watch_arg", "--watch_std_in"])
                .inheritIO().directory(project.getBasedir()).start()
            } else {
                def proc = new ProcessBuilder(["external_app", "--run_once_arg"])
                .redirectErrorStream(true).directory(project.getBasedir()).start()

                proc.waitForOrKill(15000)
                proc.in.eachLine { line -> println line }
            }
            ]]></source>
        </configuration>
    </execution>
</executions>
</plugin>

Running Groovy inside Maven is a nice quick way to implement a custom plugin. This one is set up to run in the process-resources phase of the Maven life cycle. The first thing we do is determine if we are running with jetty:run or as part of a normal build because we want to handle the situations differently.

When running as part of the normal build process everything is straight forward - build up a process that uses our external tool and pass it whatever arguments it needs to process files once. We also redirect the error stream so we can get errors and output together to display with the rest of the Maven output. We kill the process if it takes longer than 15 seconds and the loop through the output writing it out to the console.

When running with Jetty, our external tool will have to support some special options. It will need to be able to keep itself running and watch for file changes to re-do the pre-processing. It will also need to watch std-in and exit when std-in closes. That last option may sound a little strange as a requirement but there is a reason for it. We could have added shutdown hooks and killed our process when Maven shuts down; but shutdown hooks won't run if Maven is stopped with a SIG_KILL. If you run Maven inside an IDE like IntelliJ, the stop button does a SIG_KILL and will leave your processes running. So to work around this we require our external tool to watch for std-in to close and then when we build our process we inherit the IO of the parent. Now std-in of our process is the same as the std-in of Maven and when Maven shuts down for any reason our process will exit itself.

The next post will build on this and show a complete example for live pre-processing of .less files.