Jetty/Feature/Jetty Maven Plugin
2015-10-27 10:07
435 查看
url:http://wiki.eclipse.org/Jetty/Feature/Jetty_Maven_Plugin#Configuring_Connectors
Introduction
2
Feature
3
Quick Start: Get Up and Running
3.1
Stopping the Plugin
4
Running and Deploying
5
Configuring the Jetty Container
6
Configuring Your WebApp
6.1
jetty:run : Running an unassembled webapp
6.1.1
Configuring additional parameters
6.2
jetty:run-war : Running an assembled webapp as a war
6.2.1
Configuring the war
6.3
jetty:run-exploded : Running an assembled webapp as an expanded WAR
6.3.1
Configuring the exploded war
6.4
jetty:deploy-war : Running a pre-assembled war
6.5
jetty:run-forked : Running an unassembled webapp in a separate jvm
6.6
jetty:start : Starting jetty without first executing the build up to "test-compile" phase
7
More
7.1
Excluded Goals
7.2
Manual Reload
7.3
Stopping the plugin from Another Terminal Window
7.4
Using mvn jetty:help for More Help
7.5
Skipping execution of jetty
7.6
Configuring Security Settings
7.7
Configuring Connectors
7.8
Using Overlayed WARs
7.9
Multiple webapp root directories
7.10
Using GZip Compression and Other Jetty Extensions
7.11
Running more than one webapp
7.12
Setting System Properties
7.12.1
In the Pom
7.12.2
In a File
Jetty 7 and Jetty 8 are now EOL (End of Life)
All development and stable releases are being performed with Jetty 9.
This wiki is now officially out of date and all content has been moved to the
Jetty Documentation Hub
Direct Link to updated documentation: http://www.eclipse.org/jetty/documentation/current/jetty-maven-plugin.html
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.
You will need to use maven 3 from jetty-7.5.3 release going forwards.
This documentation ONLY refers to using the jetty-maven-plugin with Jetty 7.x or Jetty 8.x.
For Jetty 9.x an onward, this wiki has been replaced with a docbook documentation, found at
http://www.eclipse.org/jetty/documentation/current/jetty-maven-plugin.html
Then, from the same directory as your root pom.xml, simply type:
This starts Jetty and serves up your project on http://localhost:8080/.
Jetty continues 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.
To run the jetty-maven-plugin with a particular goal, use this command:
Here are the configuration elements that are common to all goals:
<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.server.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 three
other ways to configure the RequestLog:
In a jetty xml config file (specified in the <jettyXml> parameter).
In a
context xml config file (specified in the <contextXml> parameter).
In the <webApp> element.
Configuring Request Logs tutorial.
except for run-forked and stop:
<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> the path from which Jetty will serve static resources. Defaults to src/main/webapp.
<resourceBases> use instead of <baseResource> if you have multiple dirs from which you want to serve static content. This is an array of dir names.
<baseAppFirst> Optional. Defaults to "true". Controls whether any overlayed wars are added before or after the original base resource(s) of the webapp.
<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. Note that these can also be made in a <jettyXml>
file if you want them to apply to more than one webapp.
<containerIncludeJarPattern>. Since jetty-8.1.x. Optional. A pattern to match against the urls of the jars on the container path to select those that should be examined for things like META-INF fragments, resources, tlds and class inheritance
hierarchy (used with
servlet container initializers).
<webInfIncludeJarPattern>. Since jetty-8.1.6. Optional. A pattern to match against the urls of the jars considered to be on the webapp's WEB-INF classpath to select those that should be examined for META-INF fragments, resources, tlds,
and class inheritance hierarchy (used with
servlet container initializers). The default is to potentially examine them all, subject to any ordering exclusions configured in web.xml.
<contextXml> Optional The path to a context xml file that is applied to your webapp AFTER the <webApp> element.
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":
<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.
<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:
If, for whatever reason, you cannot run on an unassembled webapp, the goals
run-war and run-exploded will work on unassembled webapps.
scanInterval Jetty watches your pom.xml and the WAR file; if either changes, it redeploys the war.
Here's how to set it:
Here's how to set it:
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:
that you can use many of the goals with the same configuration). The configuration options are:
<jettyXml> The locations of jetty xml configuration files used to configure the container in the new jvm.
<contextXml> Optional. The location of a context xml file to configure the webapp in the new jvm.
<contextPath> Optional. The context path for the webapp in the new jvm. Defaults to "/${project.artifactId}". This will
override a setting inside a <contextXml> file.
<webAppSourceDirectory> Optional. The location of the static resources for your webapp. Defaults to "src/main/webapp". This will
override a <Set name="baseResource"> setting inside a <contextXml> file.
<resourceDirs> Optional. New in jetty-7.6.5. An array of directories containing static content that form the resource base for your webapp, in conjuction with the <webAppSourceDirectory>. See also <baseAppFirst>.
<baseAppFirst> Optional. New in jetty-7.6.5. Defaults to "true". Controls whether the <webAppSourceDirectory> or <resourceDirs> are first on the list of resources that form the base resource for the webapp.
<webXml> Optional. The location of the web.xml file. Defaults to "src/main/webapp/WEB-INF/web.xml". This will
override a <Set name="descriptor"> inside a <contextXml> file.
<tmpDirectory> Optional. The location of the temporary work directory. Defaults to "target/tmp". This will
override a <Set name="tempDirectory"> inside a <contextXml> file.
<classesDirectory> Optional. The location of the compiled classes for the webapp. Defaults to "${project.build.outputDirectory}"
<testClassesDirectory> Optional. The location of the compiled test classes for the webapp. Defaults to "${project.build.testOutputDirectory}"
<useTestScope> Optional. Defaults to "false". If true, the test classes and dependencies of scope "test" are placed on the webapp's classpath.
<useProvidedScope> Optional. Defaults to "false". If true, the dependencies of scope "provided" are placed on the jetty container's classpath.
<stopPort> Mandatory. A port number for jetty to listen on to receive a stop command to cause it to shutdown. If configured, the stopKey is used to authenticate an incoming stop command.
<stopKey> Mandatory. A string value that has to be sent to the stopPort to authenticate the stop command.
<skip> Optional. Defaults to "false". If true, the execution of this plugin is skipped.
<jvmArgs> Optional. A String representing arbitrary arguments to pass to the forked jvm.
<waitForChild> New in jetty-7.6.5. Optional. Defaults to "true". If true, the parent waits for the exec'ed jetty to complete. If false, the parent completes, leaving the exec'ed jetty process running, in which case you need to use mvn jetty:stop
to kill it.
To deploy your unassembled web app to jetty running in a new jvm:
With <waitForChild>true</waitForChild>:
The jetty plugin will continue to execute until either -
you hit <cntrl-c> in the terminal window to stop the plugin, which will also stop the forked jvm
or
you use "mvn jetty:stop" to stop the forked jvm, which will also stop the plugin
With <waitForChild>false</waitForChild>:
The jetty plugin will fork the child process and then exit.
NOTE: if you would like to set a custom port, you will need to specify it in a jetty.xml file rather than setting the <connector><port></port></connector> tags. The location of the jetty.xml can be specified using the jettyXml parameter.
that all necessary classes and files of the webapp have been generated. This is most useful when you want to control the start and stop of jetty via execution bindings in your pom.xml.
For example, you can configure the plugin to start your webapp at the beginning of your unit tests and stop at the end. To do this, you need to set up a couple of
Of course, you can use this goal from the command line (mvn jetty:start), however, you need to be sure that all generated classes and files for your webapp are already present first.
<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:
<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.
stop goal:
<stopPort> A port number for jetty to listen on to receive a stop command to cause it to shutdown.
<stopKey> A string value that has to be sent to the stopPort to validate the stop command.
Here's a configuration example:
Then, while Jetty is running, type:
The
mvn jetty:help -Ddetail=true -Dgoal=<goal-name> prints a list of the settable properties for that goal, in addition to its description.
You can also use the <skip> configuration parameter to skip jetty during certain executions (see above).
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:
multiple files. There is no special configuration for this beyond simply declaring the dependencies.
For example, suppose our webapp depends on these two WARs:
Suppose the webapps contain:
Then our webapp will have available these additional resources:
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:
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:
contextHandlers configuration element in the jetty plugin
configuration to do so. Say you have a webapp A, and you'd also like to deploy webapps B and C in the same jetty instance.
Putting the configuration in webapp A's pom.xml:
Alternatively, add a jetty.xml file to webapp A. Copy the
jetty.xml file from the jetty distribution, and then add WebAppContexts for the other 2 webapps:
Then configure the location of this jetty.xml file into webapp A's jetty plugin:
For either of these solutions, the other webapps must already have been built, and they are not automatically monitored for changes. You can refer either to the packed war file of the pre-built webapps or to their expanded equivalents.
have already been established.
NOTE also that configuring logging using this method of setting system properties may not work as the logging system may initialize BEFORE the jetty plugin can set the system properties.
You may find it useful instead to use the
properties maven plugin directly in your pom to set system properties which must be evaluated
before any jetty code executes. Eg:
an example:
As of jetty-7.6.5, you CAN cause the system properties defined in the pom to override those on the command line, by using the <force> parameter:
Here's an example of the file:
Here's an example of configuring the file for the plugin, although you can instead specify the file by setting the System property (!)
jetty.systemPropertiesFile on the command line:
Contents
1Introduction
2
Feature
3
Quick Start: Get Up and Running
3.1
Stopping the Plugin
4
Running and Deploying
5
Configuring the Jetty Container
6
Configuring Your WebApp
6.1
jetty:run : Running an unassembled webapp
6.1.1
Configuring additional parameters
6.2
jetty:run-war : Running an assembled webapp as a war
6.2.1
Configuring the war
6.3
jetty:run-exploded : Running an assembled webapp as an expanded WAR
6.3.1
Configuring the exploded war
6.4
jetty:deploy-war : Running a pre-assembled war
6.5
jetty:run-forked : Running an unassembled webapp in a separate jvm
6.6
jetty:start : Starting jetty without first executing the build up to "test-compile" phase
7
More
7.1
Excluded Goals
7.2
Manual Reload
7.3
Stopping the plugin from Another Terminal Window
7.4
Using mvn jetty:help for More Help
7.5
Skipping execution of jetty
7.6
Configuring Security Settings
7.7
Configuring Connectors
7.8
Using Overlayed WARs
7.9
Multiple webapp root directories
7.10
Using GZip Compression and Other Jetty Extensions
7.11
Running more than one webapp
7.12
Setting System Properties
7.12.1
In the Pom
7.12.2
In a File
Introduction
Jetty 7 and Jetty 8 are now EOL (End of Life)
All development and stable releases are being performed with Jetty 9.
This wiki is now officially out of date and all content has been moved to the
Jetty Documentation Hub
Direct Link to updated documentation: http://www.eclipse.org/jetty/documentation/current/jetty-maven-plugin.html
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.
You will need to use maven 3 from jetty-7.5.3 release going forwards.
This documentation ONLY refers to using the jetty-maven-plugin with Jetty 7.x or Jetty 8.x.
For Jetty 9.x an onward, this wiki has been replaced with a docbook documentation, found at
http://www.eclipse.org/jetty/documentation/current/jetty-maven-plugin.html
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 continues 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 a number of distinct 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.server.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 three
other ways to configure the RequestLog:
In a jetty xml config file (specified in the <jettyXml> parameter).
In a
context xml config file (specified in the <contextXml> parameter).
In the <webApp> element.
Configuring Request Logs tutorial.
Configuring Your WebApp
These configuration parameters apply to your webapp. They should apply to all goals,except for run-forked and stop:
<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> the path from which Jetty will serve static resources. Defaults to src/main/webapp.
<resourceBases> use instead of <baseResource> if you have multiple dirs from which you want to serve static content. This is an array of dir names.
<baseAppFirst> Optional. Defaults to "true". Controls whether any overlayed wars are added before or after the original base resource(s) of the webapp.
<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. Note that these can also be made in a <jettyXml>
file if you want them to apply to more than one webapp.
<containerIncludeJarPattern>. Since jetty-8.1.x. Optional. A pattern to match against the urls of the jars on the container path to select those that should be examined for things like META-INF fragments, resources, tlds and class inheritance
hierarchy (used with
servlet container initializers).
<webInfIncludeJarPattern>. Since jetty-8.1.6. Optional. A pattern to match against the urls of the jars considered to be on the webapp's WEB-INF classpath to select those that should be examined for META-INF fragments, resources, tlds,
and class inheritance hierarchy (used with
servlet container initializers). The default is to potentially examine them all, subject to any ordering exclusions configured in web.xml.
<contextXml> Optional The path to a context xml file that is applied to your webapp AFTER the <webApp> element.
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 overridethese 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 most 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.
<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.
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-zeroscanInterval 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>
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>
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>
jetty:run-forked : Running an unassembled webapp in a separate jvm
This goal is new in jetty-7.5.2. You can force jetty to start the webapp in a new jvm, optionally passing arguments to the jvm. Unlike the other goals, this one does not share all the same configuration parameters (although a lot of them are the same, sothat you can use many of the goals with the same configuration). The configuration options are:
<jettyXml> The locations of jetty xml configuration files used to configure the container in the new jvm.
<contextXml> Optional. The location of a context xml file to configure the webapp in the new jvm.
<contextPath> Optional. The context path for the webapp in the new jvm. Defaults to "/${project.artifactId}". This will
override a setting inside a <contextXml> file.
<webAppSourceDirectory> Optional. The location of the static resources for your webapp. Defaults to "src/main/webapp". This will
override a <Set name="baseResource"> setting inside a <contextXml> file.
<resourceDirs> Optional. New in jetty-7.6.5. An array of directories containing static content that form the resource base for your webapp, in conjuction with the <webAppSourceDirectory>. See also <baseAppFirst>.
<baseAppFirst> Optional. New in jetty-7.6.5. Defaults to "true". Controls whether the <webAppSourceDirectory> or <resourceDirs> are first on the list of resources that form the base resource for the webapp.
<webXml> Optional. The location of the web.xml file. Defaults to "src/main/webapp/WEB-INF/web.xml". This will
override a <Set name="descriptor"> inside a <contextXml> file.
<tmpDirectory> Optional. The location of the temporary work directory. Defaults to "target/tmp". This will
override a <Set name="tempDirectory"> inside a <contextXml> file.
<classesDirectory> Optional. The location of the compiled classes for the webapp. Defaults to "${project.build.outputDirectory}"
<testClassesDirectory> Optional. The location of the compiled test classes for the webapp. Defaults to "${project.build.testOutputDirectory}"
<useTestScope> Optional. Defaults to "false". If true, the test classes and dependencies of scope "test" are placed on the webapp's classpath.
<useProvidedScope> Optional. Defaults to "false". If true, the dependencies of scope "provided" are placed on the jetty container's classpath.
<stopPort> Mandatory. A port number for jetty to listen on to receive a stop command to cause it to shutdown. If configured, the stopKey is used to authenticate an incoming stop command.
<stopKey> Mandatory. A string value that has to be sent to the stopPort to authenticate the stop command.
<skip> Optional. Defaults to "false". If true, the execution of this plugin is skipped.
<jvmArgs> Optional. A String representing arbitrary arguments to pass to the forked jvm.
<waitForChild> New in jetty-7.6.5. Optional. Defaults to "true". If true, the parent waits for the exec'ed jetty to complete. If false, the parent completes, leaving the exec'ed jetty process running, in which case you need to use mvn jetty:stop
to kill it.
To deploy your unassembled web app to jetty running in a new jvm:
mvn jetty:run-forked
With <waitForChild>true</waitForChild>:
The jetty plugin will continue to execute until either -
you hit <cntrl-c> in the terminal window to stop the plugin, which will also stop the forked jvm
or
you use "mvn jetty:stop" to stop the forked jvm, which will also stop the plugin
With <waitForChild>false</waitForChild>:
The jetty plugin will fork the child process and then exit.
NOTE: if you would like to set a custom port, you will need to specify it in a jetty.xml file rather than setting the <connector><port></port></connector> tags. The location of the jetty.xml can be specified using the jettyXml parameter.
jetty:start : Starting jetty without first executing the build up to "test-compile" phase
This goal is new in jetty-7.6.0. This goal is designed to be used with an execution binding in your pom.xml. It is just like the jetty:run goal, however the difference is that it does NOT first execute the build up until the "test-compile" phase to ensurethat all necessary classes and files of the webapp have been generated. This is most useful when you want to control the start and stop of jetty via execution bindings in your pom.xml.
For example, you can configure the plugin to start your webapp at the beginning of your unit tests and stop at the end. 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-testand
post-integration-testMaven 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>start</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>
Of course, you can use this goal from the command line (mvn jetty:start), however, you need to be sure that all generated classes and files for your webapp are already present first.
More
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 thestop goal:
<stopPort> A port number for jetty to listen on to receive a stop command to cause it to shutdown.
<stopKey> A string value that has to be sent to the stopPort to validate the stop command.
Here's a configuration example:
<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.
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 systemproperty 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 inmultiple 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 theOverlaid 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>
Running more than one webapp
You can use either a jetty.xml file to configure extra (pre-compiled) webapps that you wish to deploy, or you can use thecontextHandlers configuration element in the jetty plugin
configuration to do so. Say you have a webapp A, and you'd also like to deploy webapps B and C in the same jetty instance.
Putting the configuration in webapp A's pom.xml:
<plugin> <groupId>org.mortbay.jetty</groupId> <artifactId>jetty-maven-plugin</artifactId> <configuration> <scanIntervalSeconds>10</scanIntervalSeconds> <webApp> <contextPath>/test</contextPath> </webApp> <contextHandlers> <contextHandler implementation="org.eclipse.jetty.webapp.WebAppContext"> <war>${basedir}../../B.war</war> <contextPath>/B</contextPath> </contextHandler> <contextHandler implementation="org.eclipse.jetty.webapp.WebAppContext"> <war>${basedir}../../C.war</war> <contextPath>/B</contextPath> </contextHandler> </contextHandlers> </configuration> </plugin>
Alternatively, add a jetty.xml file to webapp A. Copy the
jetty.xml file from the jetty distribution, and then add WebAppContexts for the other 2 webapps:
<Ref id="Contexts"> <Call name="addHandler"> <Arg> <New class="org.eclipse.jetty.webapp.WebAppContext"> <Set name="contextPath">/B</Set> <Set name="war">../../B.war</Set> </New> </Arg> </Call> <Call> <Arg> <New class="org.eclipse.jetty.webapp.WebAppContext"> <Set name="contextPath">/C</Set> <Set name="war">../../C.war</Set> </New> </Arg> </Call> </Ref>
Then configure the location of this jetty.xml file into webapp A's jetty plugin:
<plugin> <groupId>org.mortbay.jetty</groupId> <artifactId>jetty-maven-plugin</artifactId> <configuration> <scanIntervalSeconds>10</scanIntervalSeconds> <webApp> <contextPath>/test</contextPath> </webApp> <jettyXml>src/main/etc/jetty.xml</jettyXml> </configuration> </plugin>
For either of these solutions, the other webapps must already have been built, and they are not automatically monitored for changes. You can refer either to the packed war file of the pre-built webapps or to their expanded equivalents.
Setting System Properties
As a convenience, you can specify property name/value pairs that Jetty sets as System properties for the execution of the plugin. NOTE however that some system properties MUST be set on the command line to take effect, as by the time maven runs their valueshave already been established.
NOTE also that configuring logging using this method of setting system properties may not work as the logging system may initialize BEFORE the jetty plugin can set the system properties.
You may find it useful instead to use the
properties maven plugin directly in your pom to set system properties which must be evaluated
before any jetty code executes. Eg:
<plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>properties-maven-plugin</artifactId> <version>1.0-alpha-2</version> <executions> <execution> <goals> <goal>set-system-properties</goal> </goals> <configuration> <properties> <property> <name>logback.configurationFile</name> <value>${project.baseUri}/resources/logback.xml</value> </property> </properties> </configuration> </execution> </executions> </plugin>
In the Pom
Note that if a System property is found that is already set (for example, from the command line or by the JVM itself), then these configured properties DO NOT override them. This feature is useful to tidy up the command line and save a lot of typing. Here'san example:
<plugin> <groupId>org.mortbay.jetty</groupId> <artifactId>jetty-maven-plugin</artifactId> <configuration> <systemProperties> <systemProperty> <name>fooprop</name> <value>222</value> </systemProperty> </systemProperties> <webApp> <contextPath>/test</contextPath> </webApp> </configuration> </plugin>
As of jetty-7.6.5, you CAN cause the system properties defined in the pom to override those on the command line, by using the <force> parameter:
<plugin> <groupId>org.mortbay.jetty</groupId> <artifactId>jetty-maven-plugin</artifactId> <configuration> <systemProperties> <force>true</force> <systemProperty> <name>fooprop</name> <value>222</value> </systemProperty> </systemProperties> <webApp> <contextPath>/test</contextPath> </webApp> </configuration> </plugin>
In a File
You can also specify your System properties in a file. System properties specified in this way do NOT override System properties that have been set on the command line, by the JVM, or directly in the POM via systemProperties.Here's an example of the file:
fooprop=222
Here's an example of configuring the file for the plugin, although you can instead specify the file by setting the System property (!)
jetty.systemPropertiesFile on the command line:
<plugin> <groupId>org.mortbay.jetty</groupId> <artifactId>jetty-maven-plugin</artifactId> <configuration> <systemPropertiesFile>${basedir}/mysys.props</systemPropertiesFile> <webApp> <contextPath>/test</contextPath> </webApp> </configuration> </plugin>
相关文章推荐
- 了解jQuery
- 新手在js里面看到$符号,很奇怪,啥东西
- ReactJS入门
- 关于reset.css的疑问:为什么一定要重置浏览器样式?
- JSON.parse()和eval()的区别
- html5本次存储几种方式
- 织梦arclist 五条文章,每条显示的CSS样式不一样。实现方式如下。
- 理解JavaScript的作用域链
- node.js(3) 模块加载机制
- JS实现浏览器状态栏文字从右向左弹出效果代码
- jQuery中$.get、$.post、$.getJSON和$.ajax的用法详解
- NiftyDialogEffects-多种弹出效果的对话框
- 基于SpringMVC与jquery的ajax提交表单的若干情况详解
- 有关AngularJS请求Web API资源的思路
- 40款 Javascript common plugins
- jQuery停止动画和判断是否处于动画状态
- 解决IE(IE6/IE7/IE8)不兼容HTML5标签的方法
- node-webkit-MusicBox 基于nwjs ,html5 ,制作的音乐盒子
- JSON.parse()和JSON.stringify()
- JQM[jquery mobile] 实战经验汇总