Difference between revisions of "Jetty/Feature/Jetty Maven Plugin"

Revision as of 21:36, 6 October 2011

Introduction

The Jetty Maven plugin is useful for rapid development and testing. You can add it to any webapp project that is structured according to the usual Maven defaults. The plugin can then periodically scan your project for changes and automatically redeploy the webapp if any are found. This makes the development cycle more productive by eliminating the build and deploy steps: you use your IDE to make changes to the project, and the running web container automatically picks them up, allowing you to test them straight away.

The information on this page refers to the plugin versions for Jetty 7 and above. If you're using the plugin with Jetty 6, see the Jetty 6 Maven Plugin guide at codehaus. It is now called the jetty-maven-plugin. In previous versions it was the maven-jetty-plugin.

Feature

Quick Start: Get Up and Running

First, add jetty-maven-plugin to your pom.xml definition:

<plugin>
  <groupId>org.mortbay.jetty</groupId>
  <artifactId>jetty-maven-plugin</artifactId>
</plugin>

Then, from the same directory as your root pom.xml, simply type:

 mvn jetty:run

This starts Jetty and serves up your project on http://localhost:8080/.

Jetty will continue to run until you stop it. While it runs, it periodically scans for changes to your project files, so if you save changes and recompile your class files, Jetty redeploys your webapp, and you can instantly test the changes you just made.

Stopping the Plugin

You can terminate the plugin with a <ctrl-c> in the terminal window where it is running.

Running and Deploying

The jetty-maven-plugin has six Maven goals. Each goal is an action you can run to accomplish a specific task, or to work with a particular web application setup. You might need to insert goal-specific configuration to run it properly.

To run the jetty-maven-plugin with a particular goal, use this command:

 mvn jetty:goalname

Here are the configuration elements that are common to all goals:

Configuring the Jetty Container

These configuration elements set up the Jetty environment in which your webapp executes.

• <connectors> Optional A list of org.eclipse.jetty.server.Connector objects, which are the port listeners for Jetty. If you don't specify any, an NIO org.eclipse.jetty.nio.SelectChannelConnector will be configured on port 8080. You can change this default port number by using the system property jetty.port on the command line, for example, "mvn -Djetty.port=9999 jetty:run". Alternatively, you can specify as many connectors as you like. You could also instead configure the connectors in a standard [jetty xml config] file and put its location into the <jettyXml> parameter.

• <jettyXml> Optional The location of a jetty.xml file that will be applied in addition to any plugin configuration parameters. You might use it if you have other webapps, handlers, etc. to deploy, or if you have other Jetty objects that cannot be configured from the plugin.

• <scanIntervalSeconds> Optional The pause in seconds between sweeps of the webapp to check for changes and automatically hot redeploy if any are detected. By default this is 0, which disables hot deployment scanning. A number greater than 0 enables it.

• <systemProperties> Optional Allow you to configure System properties for the execution of the plugin. For more information, see Setting System Properties.

• <systemPropertiesFile> Optional A file containing System properties to set for the execution of the plugin. Settings that you make here do not override any system properties already set on the command line, by the JVM, or in the POM via systemProperties. Available from Jetty 6.1.15rc4.

• <loginServices> Optional A list of org.eclipse.jetty.security.LoginService implementations. Note that there is no default realm. If you use a realm in your web.xml you can specify a corresponding realm here. You could instead configure the login services in a jetty xml file and add its location to the <jettyXml> parameter.

• <requestLog> Optional An implementation of the org.eclipse.jetty.server.RequestLog request log interface. An implementation that respects the NCSA format is available as org.eclipse.jetty.server.NCSARequestLog. There are 3 other ways to configure the RequestLog:

1. 1. In a jetty xml config file (specified in the <jettyXml> parameter)
   2. In a [context xml config file] (specified in the <contextXml> parameter)
   3. In the <webApp> element. [Here is a tutorial] on configuring request logs.

Configuring Your WebApp

These configuration parameters apply to your webapp.

• <webApp> Represents an extension to the class [org.eclipse.jetty.webapp.WebAppContext]. Any of the setter methods on this object can be used to configure your webapp. Here are a few of the most useful ones:
  • <contextPath> The context path for your webapp. By default, this is set to the /${project.artifactId} from the project's pom.xml.
  • <descriptor> The path to the web.xml file for your webapp.
  • <defaultsDescriptor> The path to a webdefault.xml file that will be applied to your webapp before the web.xml. If none is supplied, Jetty uses a default one baked into the jetty-webapp.jar.
  • <overrideDescriptor> The path to a web.xml file that will be applied after your web.xml is read. You can use this to replace or add configuration.
  • <tempDirectory> The path to a dir that Jetty can use to expand or copy jars and jsp compiles when your webapp is running. The default is ${project.build.outputDirectory}/tmp
  • <baseResource> and subtag <resourcesAsCSV>: the paths Jetty will serve resources from. Defaults to src/main/webapp
• <contextXml> Optional The path to a context xml file that is applied to your webapp AFTER the <webApp> element.

mvn jetty:run : Running an Unassembled webapp

The run goal runs on a webapp that does not have to be built into a WAR. Instead, Jetty deploys the webapp from its constituent sources. It looks for the constituent parts of a webapp in the maven default project locations, although you can override these in the plugin configuration. For example, by default it looks for:

• resources in ${basedir}/src/main/webapp
• classes in ${project.build.outputDirectory}
• web.xml in ${basedir}/src/main/webapp/WEB-INF/

The plugin automatically ensures the classes are rebuilt and up-to-date before deployment. If you change the source of a class and your IDE automatically compiles it in the background, the plugin picks up the changed class.

The webapp does not need to be assembled into a WAR, saving time during the development cycle. Once invoked, you can configure the plugin to run continuously, scanning for changes in the project and automatically performing a hot redeploy when necessary. Any changes you make are immediately reflected in the running instance of Jetty, letting you quickly jump from coding to testing, rather than going through the cycle of: code, compile, reassemble, redeploy, test.

Here is a small example, which turns on scanning for changes every ten seconds, and sets the webapp context path to "/test":

<plugin>
  <groupId>org.mortbay.jetty</groupId>
  <artifactId>jetty-maven-plugin</artifactId>
  <configuration>
    <scanIntervalSeconds>10</scanIntervalSeconds>
    <webApp>
      <contextPath>/test</contextPath>
    </webApp>
  </configuration>
</plugin>

Configuring Additional Parameters

In addition to the <webApp> element which is common to all goals, the jetty:run goal supports:

• <classesDirectory> – Location of your compiled classes for the webapp. You should rarely need to set this parameter. Instead, you should set <build><outputDirectory> in your pom.xml.
• <testClassesDirectory> – Location of the compiled test classes for your webapp. By default this is ${project.build.testOutputDirectory}.
• <useTestScope> – If true, the classes from <testClassesDirectory> and dependencies of scope "test" are placed first on the classpath. By default this is false.
• <useProvidedScope> - If true, the dependencies with scope "provided" are placed onto the container classpath. Note: NOT the webapp classpath, as "provided" indicates that these dependencies would normally be expected to be provided by the container. You should very rarely ever need to use this. Instead, you should copy the provided dependencies as explicit dependencies of the <plugin> instead.
• <webAppSourceDirectory> – By default, this is set to ${basedir}/src/main/webapp. If your static sources are in a different location, set this parameter accordingly.
• <jettyEnvXml> –Optional Location of a jetty-env.xml file, which allows you to make JNDI bindings that satisfies <env-entry>, <resource-env-ref> and <resource-ref> linkages in the web.xml that are scoped only to the webapp and not shared with other webapps that you might be deploying at the same time (for example, by using a jettyConfig file).
• <scanTargets> –Optional A list of files and directories to periodically scan in addition to those automatically scanned by the plugin.
• <scanTargetPatterns> –Optional If you have a long list of extra files you want scanned, it is more convenient to use pattern matching expressions to specify them instead of enumerating them with the <scanTargets>–List of <scanTargetPattern>s, each consisting of a <directory,> and <including> and/or <excluding> parameters to specify the file matching patterns.
• <skip> - Optional Default is false. If true, the execution of the plugin will exit. Same as setting the SystemProperty -Djetty.skip on the command line.

Here's an example:

<project>
  ...
  <plugins>
    ...
      <plugin>
        <groupId>org.mortbay.jetty</groupId>
        <artifactId>jetty-maven-plugin</artifactId>
        <configuration>
          <webAppSourceDirectory>${basedir}/src/staticfiles</webAppSourceDirectory>
          <webAppConfig>
            <contextPath>/</contextPath>
            <descriptor>${basedir}/src/over/here/web.xml</descriptor>
            <jettyEnvXml>${basedir}/src/over/here/jetty-env.xml</jettyEnvXml>
          </webAppConfig>
          <classesDirectory>${basedir}/somewhere/else</classesDirectory>
          <scanTargets>
            <scanTarget>src/mydir</scanTarget>
            <scanTarget>src/myfile.txt</scanTarget>
          </scanTargets>
          <scanTargetPatterns>
            <scanTargetPattern>
              <directory>src/other-resources</directory>
              <includes>
                <include>**/*.xml</include>
                <include>**/*.properties</include>
              </includes>
              <excludes>
                <exclude>**/myspecial.xml</exclude>
                <exclude>**/myspecial.properties</exclude>
              </excludes>
            </scanTargetPattern>
          </scanTargetPatterns>
        </configuration>
      </plugin>
  </plugins>
</project>

If, for whatever reason, you cannot run on an unassembled webapp, the goals run-war and run-exploded will work on unassembled webapps.

mvn jetty:run-war : Running an Assembled webapp as a WAR

This goal first packages your webapp as a WAR file and then deploys it to Jetty. If you set a non-zero scanInterval Jetty watches your pom.xml and the WAR file; if either changes, it redeploys the WAR.

Configuring the WAR

• <war> The location of the built WAR file. This defaults to ${project.build.directory}/${project.build.finalName}.war. If this is not sufficient, set it to your custom location.

Here's how to set it:

<project>
  ...
  <plugins>
    ...
      <plugin>
        <groupId>org.mortbay.jetty</groupId>
        <artifactId>jetty-maven-plugin</artifactId>
        <configuration>
          <war>${basedir}/target/mycustom.war</war>
        </configuration>
      </plugin>
  </plugins>
</project>

mvn jetty:run-exploded  : Running an Assembled webapp as an Expanded WAR

The run-exploded goal first assembles your webapp into an exploded WAR file and then deploys it to Jetty. If you set a non-zero scanInterval, Jetty watches your pom.xml, WEB-INF/lib, WEB-INF/classes and WEB-INF/web.xml for changes and redeploys when necessary.

Configuring the Exploded WAR

• <war> The location of the exploded WAR. This defaults to ${project.build.directory}/${project.build.finalName}, but you can override the default by setting this parameter.

Here's how to set it:

<project>
  ...
  <plugins>
    ...
      <plugin>
        <groupId>org.mortbay.jetty</groupId>
        <artifactId>maven-jetty-plugin</artifactId>
        <configuration>
          <war>${basedir}/target/myfunkywebapp</war>
        </configuration>
      </plugin>
  </plugins>
</project>

mvn jetty:deploy-war  : Running a Pre-assembled WAR

This is basically the same as jetty:run-war, but without assembling the WAR of the current module. Unlike run-war, the phase in which this plugin executes is not bound to the "package" phase.

For example, you might want to start Jetty on the test-compile phase and stop Jetty on the test-phase. Here's the configuration for that:

<project>
  ...
  <plugins>
    ...
      <plugin>
        <groupId>org.mortbay.jetty</groupId>
        <artifactId>jetty-maven-plugin</artifactId>
        <configuration>
          <war>${basedir}/target/mycustom.war</war>
        </configuration>
        <executions>
          <execution>
            <id>start-jetty</id>
            <phase>test-compile</phase>
            <goals>
              <goal>deploy-war</goal>
            </goals>
            <configuration>
              <daemon>true</daemon>
              <reload>manual</reload>
            </configuration>
          </execution>
          <execution>
            <id>stop-jetty</id>
            <phase>test</phase>
            <goals>
              <goal>stop</goal>
            </goals>
          </execution>
        </executions>
      </plugin>
  </plugins>
</project>

mvn jetty:run-forked  : Running an unassembled webapp in a separate jvm

This goal is new in jetty-7.5.2.

More

The following sections provide additional information about the Jetty Maven plugin.

Excluded Goals

Sometimes, your webapp might simply not be able to work with one of the goals, for example "jetty:run". In this case, use the <excludedGoals> parameter:

• <excludedGoals> Optional Set to a comma separated list of jetty goal names which, if executed, will cause the plugin to print an informative message and exit immediately:

<configuration>
   <excludedGoals>run,run-exploded</excludedGoals>
</configuration>

Manual Reload

Sometimes you may not want jetty to automatically reload and redeploy your webapp when something about it has changed. For example, you may be doing a series of changes and you want to ignore them all until you're done. In that use, use the <reload> parameter:

• <reload> Optional Default value is automatic. If 'manual' then the context can be reloaded by a linefeed in the console. If 'automatic' then traditional reloading on changed files is enabled.

Stopping the plugin from Another Terminal Window

If you want to use mvn jetty:stop, you need to configure the plugin with a special port number and key that you also supply by executing the stop Goal:

<plugin>
  <groupId>org.mortbay.jetty</groupId>
  <artifactId>jetty-maven-plugin</artifactId>
  <configuration>
    <stopPort>9966</stopPort>
    <stopKey>foo</stopKey>
  </configuration>
</plugin>

Then, while Jetty is running, type:

   mvn jetty:stop

The <stopPort> must be free on the machine you are running on. If this is not the case, you get an "Address already in use" error message after the "Started SelectedChannelConnector ..." message.

Using mvn jetty:help for More Help

mvn jetty:help prints the list of goals for the jetty-maven-plugin, with a description of each goal.

mvn jetty:help -Ddetail=true -Dgoal=<goal-name> prints a list of the settable properties for that goal, in addition to its description.

Setting mvn jetty:run for Automatic Plugin Execution During Unit Testing

Automatic plugin execution is a useful feature. You can configure the plugin to start your webapp at the beginning of your unit tests and stop at the end, rather than manually executing mvn jetty:run on the command line. To do this, you need to set up a couple of <execution> scenarios for the Jetty plugin and use the <daemon>true</daemon> configuration option to force Jetty to execute only while Maven is running, instead of running indefinitely. You use the pre-integration-test and post-integration-test Maven build phases to trigger the execution and termination of Jetty:

<plugin>
  <groupId>org.mortbay.jetty</groupId>
  <artifactId>jetty-maven-plugin</artifactId>
  <configuration>
    <scanIntervalSeconds>10</scanIntervalSeconds>
    <stopKey>foo</stopKey>
    <stopPort>9999</stopPort>
  </configuration>
  <executions>
    <execution>
      <id>start-jetty</id>
      <phase>pre-integration-test</phase>
      <goals>
        <goal>run</goal>
      </goals>
      <configuration>
       <scanIntervalSeconds>0</scanIntervalSeconds>
       <daemon>true</daemon>
      </configuration>
    </execution>
    <execution>
      <id>stop-jetty</id>
      <phase>post-integration-test</phase>
      <goals>
        <goal>stop</goal>
      </goals>
    </execution>
  </executions>
</plugin>

Skipping execution of jetty

Similarly to the well known system property "mvn.test.skip", you can define the system property "jetty.skip" to prevent jetty running. This is most useful when configuring jetty for execution during integration testing and you want to skip the tests:

   mvn -Djetty.skip=true

You can also use the <skip> configuration parameter to skip jetty during certain executions (see above).

Configuring Security Settings

You can configure LoginServices (this was known as UserRealms in Jetty 6) in the plugin. Here's an example of setting up the HashLoginService for a webapp:

<plugin>
  <groupId>org.mortbay.jetty</groupId>
  <artifactId>jetty-maven-plugin</artifactId>
  <configuration>
    <scanIntervalSeconds>10</scanIntervalSeconds>
    <webAppConfig>
      <contextPath>/test</contextPath>
    </webAppConfig>
    <loginServices>
      <loginService implementation="org.eclipse.jetty.security.HashLoginService">
        <name>Test Realm</name>
        <config>${basedir}/src/etc/realm.properties</config>
      </loginService>
    </loginServices>
  </configuration>
</plugin>

Configuring Connectors

You can configure a list of org.eclipse.jetty.server.Connector objects for the plugin. If you don't specify any, an NIO org.eclipse.jetty.server.nio.SelectChannelConnector is configured on port 8080. You can change this default port number by using the system property jetty.port on the command line, for example "mvn -Djetty.port=9999 jetty:run". Alternatively, you can specify as many connectors as you like. Here's an example of configuring a connector on a different port number:

<plugin>
  <groupId>org.mortbay.jetty</groupId>
  <artifactId>jetty-maven-plugin</artifactId>
  <configuration>
    <scanIntervalSeconds>10</scanIntervalSeconds>
    <webApp>
      <contextPath>/test</contextPath>
    </webApp>
    <connectors>
       <connector implementation="org.eclipse.jetty.server.nio.SelectChannelConnector">
          <port>9090</port>
          <maxIdleTime>60000</maxIdleTime>
       </connector>
     </connectors>
  </configuration>
</plugin>

Using Overlayed WARs

If your webapp depends on other WAR files, the Jetty Maven plugin is able to merge resources from all of them. The merging is fairly simple and does not support exclusions. The ordering of dependencies is important if you have the same resource defined in multiple files. There is no special configuration for this beyond simply declaring the dependencies.

For example, suppose our webapp depends on these two WARs:

    <dependency>
      <groupId>com.acme</groupId>
      <artifactId>X</artifactId>
      <type>war</type>
    </dependency>
    <dependency>
      <groupId>com.acme</groupId>
      <artifactId>Y</artifactId>
      <type>war</type>
    </dependency>

Suppose the webapps contain:

WebAppX:
 
/foo.jsp
/bar.jsp
/WEB-INF/web.xml
 
 
 
WebAppY:
 
/bar.jsp
/baz.jsp
/WEB-INF/web.xml
/WEB-INF/special.xml

Then our webapp will have available these additional resources:

/foo.jsp (X)
/bar.jsp (X)
/baz.jsp (Y)
/WEB-INF/web.xml (X)
/WEB-INF/sitemesh.xml (Y)

Multiple webapp root directories

If you have external resources that you want to incorporate in the execution of your webapp - but they're not assembled into wars so you can't use the Overlaid Wars method described above - then you can simply tell jetty the directories in which these external resources are located. At runtime, when jetty receives a request for a resource, it will look along all the locations to retrieve the resource. It's a lot like the overlaid war situation, without the war. Here's a configuration example:

<configuration>
  <webApp>
    <contextPath>/${build.finalName}</contextPath>
    <baseResource implementation="org.eclipse.jetty.util.resource.ResourceCollection">
      <resourcesAsCSV>src/main/webapp,/home/johndoe/path/to/my/other/source,/yet/another/folder</resourcesAsCSV>
    </baseResource>
  </webApp>
</configuration>

Using GZip Compression and Other Jetty Extensions

You must be explicit enable GZip compression and other Jetty extensions by adding a dependency on jetty-servlets:

      <plugin>
        <groupId>org.mortbay.jetty</groupId>
        <artifactId>jetty-maven-plugin</artifactId>
        <version>7.0.1.v20091125</version>
        <configuration>
          [...]
        </configuration>
        <dependencies>
          <dependency>
            <groupId>org.eclipse.jetty</groupId>
            <artifactId>jetty-servlets</artifactId>
            <version>7.0.1.v20091125</version>
          </dependency>
        </dependencies>
      </plugin>

Setting the groupId
Maven by default looks for plugins with a groupId of org.apache.maven.plugins, even if the groupId is declared differently as above. In order to instruct Maven to look for the plugin in the groupId as defined, set a plugin group in a profile in settings.xml like so:

<profile>
  ...
  <pluginGroups>
    <pluginGroup>org.mortbay.jetty</pluginGroup>
  </pluginGroups>
</profile>