Maven jetty plugin

Maven jetty plugin DEFAULT

Configuring the Jetty Maven Plugin

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 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.

Important

You should use Maven 3.3+ for this plugin.

While the Jetty Maven Plugin can be very useful for development we do not recommend its use in a production capacity. In order for the plugin to work it needs to leverage many internal Maven apis and Maven itself it not a production deployment tool. We recommend either the traditional distribution deployment approach or using embedded Jetty.

Quick Start: Get Up and Running

First, add to your definition:

Then, from the same directory as your root , type:

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 If you save changes and recompile your class files, Jetty redeploys your webapp, and you can instantly test the changes that were just made.

You can terminate the plugin with a in the terminal window where it is running.

Note

The classpath of the running Jetty instance and its deployed webapp are managed by Maven, and may not be exactly what you expect. For example: a webapp’s dependent jars might be referenced via the local repository, not the directory.

The Jetty Maven plugin has a number of distinct Maven goals. Arguably the most useful is the goal which runs Jetty on an unassembled webapp. There are other goals which help you accomplish different tasks. For example, you might need to run your webapp in a forked instance of Jetty rather than within the process running Maven; or you may need finer grained control over the maven lifecycle stage in which you wish to deploy your webapp. There are different goals to accomplish these tasks, as well as several others.

To see a list of all goals supported by the Jetty Maven plugin, do:

To see the detailed list of parameters that can be configured for a particular goal, in addition to its description, do:

mvn jetty:help -Ddetail=true -Dgoal= <goal name>

Configuring the Jetty Container

These configuration elements set up the Jetty environment in which your webapp executes. They are common to most goals:

httpConnector

Optional. If not specified, Jetty will create a ServerConnector instance listening on port 8080. You can change this default port number by using the system property on the command line, for example, . Alternatively, you can use this configuration element to set up the information for the ServerConnector. The following are the valid configuration sub-elements:

jettyXml
Optional. A comma separated list of locations of files to apply in addition to any plugin configuration parameters. You might use it if you have other webapps, handlers, specific types of connectors etc., to deploy, or if you have other Jetty objects that you cannot configure from the plugin.
scanIntervalSeconds
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.
reload
Default value is "automatic", used in conjunction with a non-zero `scanIntervalSeconds` causes automatic hot redeploy when changes are detected. Set to "manual" instead to trigger scanning by typing a linefeed in the console running the plugin. This might be useful when you are doing a series of changes that you want to ignore until you’re done. In that use, use the parameter.
dumpOnStart
Optional. Default value is false. If true, then jetty will dump out the server structure on start.
loginServices
Optional. A list of implementations. Note that there is no default realm. If you use a realm in your 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 parameter.
requestLog

Optional. An implementation of the request log interface. An implementation that respects the NCSA format is available as . There are three other ways to configure the RequestLog:

  • In a jetty xml config file, as specified in the parameter.
  • In a context xml config file, as specified in the parameter.
  • In the element.

See Configuring Request Logs for more information.

server
Optional as of Jetty 9.3.1. This would configure an instance of the for the plugin to use, however it is usually NOT necessary to configure this, as the plugin will automatically configure one for you. In particular, if you use the jettyXml element, then you generally DON’T want to define this element, as you are probably using the jettyXml file to configure up a Server with a special constructor argument, such as a custom threadpool. If you define both a server element AND use a jetty xml element which points to a config file that has a line like then the the xml configuration will override what you configure for the server in the .
stopPort
Optional. Port to listen on for stop commands. Useful to use in conjunction with the stop or run-forked goals.
stopKey
Optional. Used in conjunction with stopPort for stopping jetty. Useful when used in conjunction with the stop or run-forked goals.
systemProperties
Optional. Allows 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. By default, 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 . Read Setting System Properties for how to force overrides.
skip
Default is false. If true, the execution of the plugin exits. Same as setting the SystemProperty on the command line. This is most useful when configuring Jetty for execution during integration testing and you want to skip the tests.
useProvidedScope
Default value is . If true, the dependencies with are placed onto the container classpath. Be aware that this is 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 instead.
excludedGoals
Optional. A list of Jetty plugin goal names that will cause the plugin to print an informative message and exit. Useful if you want to prevent users from executing goals that you know cannot work with your project.

Configuring a Https Connector

In order to configure an HTTPS connector, you need to use jetty xml configuration files. This example uses files copied directly from the jetty distribution etc/ directory, although you can of course make up your own xml file or files. We will use the following files:

jetty.xml

Sets up various characteristics of the instance for the plugin to use. Importantly, it sets up the element that we can refer to in subsequent xml files that configure the connectors. Here’s the relevant section:

jetty-ssl.xml

Set up ssl which will be used by the https connector. Here’s the file from the jetty-distribution:

jetty-https.xml

Set up the https connector using the HttpConfiguration from and the ssl configuration from :

Now you need to let the plugin know to apply the files above:

Caution

Just like with an installed distribution of Jetty, the ordering of the xml files is significant.

You can also use Jetty xml files to configure a http connector for the plugin to use. Here we use the same file from the Jetty distribution:

Now we add it to the list of configs for the plugin to apply:

Alternatively, you can use the httpConnector configuration element inside the pom instead as described above.

These configuration parameters apply to your webapp. They are common to almost all goals.

webApp

This is an instance of org.eclipse.jetty.maven.plugin.JettyWebAppContext, which is an extension to the class . You can use any of the setter methods on this object 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 . If using a custom value for this parameter, you probably want to include the leading , example .
descriptor
The path to the file for your webapp.
defaultsDescriptor
The path to a file that will be applied to your webapp before the . If you don’t supply one, Jetty uses a default file baked into the .
overrideDescriptor
The path to a file that Jetty applies after reading your . 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 .
baseResource
The path from which Jetty serves static resources. Defaults to .
resourceBases
Use instead of if you have multiple directories from which you want to serve static content. This is an array of directory names.
baseAppFirst
Defaults to "true". Controls whether any overlaid wars are added before or after the original base resource(s) of the webapp. See the section on overlaid wars for more information.
containerIncludeJarPattern
Defaults to . This is a pattern that is applied to the names of the jars on the container’s classpath (ie the classpath of the plugin, not that of the webapp) that should be scanned for fragments, tlds, annotations etc. This is analogous to the context attribute org.eclipse.jetty.server.webapp.ContainerIncludeJarPattern that is documented here. You can define extra patterns of jars that will be included in the scan.
webInfIncludeJarPattern
Defaults to matching all of the dependency jars for the webapp (ie the equivalent of WEB-INF/lib). You can make this pattern more restrictive to only match certain jars by using this setter. This is analogous to the context attribute org.eclipse.jetty.server.webapp.WebInfIncludeJarPattern that is documented here.
contextXml
The path to a context xml file that is applied to your webapp AFTER the element.

The goal runs on a webapp that does not have to be built into a WAR. Instead, Jetty deploys the webapp from its 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
  • classes in
  • in

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.

You do not need to assemble the webapp 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 an example, which turns on scanning for changes every ten seconds, and sets the webapp context path to :

In addition to the element that is common to most goals, the goal supports:

classesDirectory
Location of your compiled classes for the webapp. You should rarely need to set this parameter. Instead, you should set in your .
testClassesDirectory
Location of the compiled test classes for your webapp. By default this is .
useTestScope
If true, the classes from and dependencies of scope "test" are placed first on the classpath. By default this is false.
webAppSourceDirectory
By default, this is set to . If your static sources are in a different location, set this parameter accordingly.
jettyEnvXml
Optional. Location of a file, which allows you to make JNDI bindings that satisfy , , and linkages in the 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 the plugin automatically scans.
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 of , each consisting of a directory, and including and/or excluding parameters to specify the file matching patterns.
scanClassesPattern
Since 9.3.0. Optional. Include and exclude patterns that can be applied to the classesDirectory for the purposes of scanning, it does not affect the classpath. If a file or directory is excluded by the patterns then a change in that file (or subtree in the case of a directory) is ignored and will not cause the webapp to redeploy. Patterns are specified as a relative path using a glob-like syntax as described in the javadoc for FileSystem.getPathMatcher.
scanTestClassesPattern
Since 9.3.0. Optional. Include and exclude patterns that can be applied to the testClassesDirectory for the purposes of scanning, it does not affect the classpath. If a file or directory is excluded by the patterns then a change in that file (or subtree in the case of a directory) is ignored and will not cause the webapp to redeploy. Patterns are specified as a relative path using a glob-like syntax as described in the javadoc for FileSystem.getPathMatcher.

Here’s an example:

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

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

war
The location of the built WAR file. This defaults to . If this is not sufficient, set it to your custom location.

Here’s how to set it:

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 , Jetty watches your , and for changes and redeploys when necessary.

war
The location of the exploded WAR. This defaults to , but you can override the default by setting this parameter.

Here’s how to set it:

This is basically the same as , but without assembling the WAR of the current module - you can nominate the location of any war to run. Unlike , the phase in which this plugin executes is not bound to the "package" phase - you may bind it to any phase to use it.

war
The location of the WAR file. This defaults to , but you can override the default by setting this parameter.
daemon
If true, this plugin will start Jetty but let the build continue. This is useful if you want to start jetty as an execution binding in a particular phase and then stop it in another. Alternatively, you can set this parameter to false, in which case Jetty will block and you will need to use a ctrl-c to stop it.

Here’s the configuration:

This goal allows you to start the webapp in a new JVM, optionally passing arguments to that new JVM. This goal supports the same configuration parameters as the goal with a couple of extras to help configure the forked process.

The available configuration parameters - in addition to those for the goal - are:

jvmArgs
Optional. A string representing arbitrary arguments to pass to the forked JVM.
waitForChild
Default is . This causes the parent process to wait for the forked process to exit. In this case you can use to terminate both processes. It is more useful to set it to , in which case the parent process terminates whilst leaving the child process running. You use the goal to stop the child process.
maxStartupLines
Default is . This is maximum number of lines the parent process reads from the child process to receive an indication that the child has started. If the child process produces an excessive amount of output on stdout you may need to increase this number.

Some of the container configuration parameters are NOT available with this goal:

scanIntervalSeconds
Not supported. The forked jetty will not monitor and redeploy the webapp.
reload
Not supported. The forked jetty will not redeploy the webapp.
httpConnector
Not supported. To define custom connectors use a jetty xml file instead.
loginServices
Not supported. To define LoginServices use a jetty xml or context xml file instead.
requestLog
Not supported. To define a RequestLog setup, use a jetty xml or context xml file instead.
systemProperties
Not supported. Use the parameter to pass system properties to the forked process.

To deploy your unassembled web app to Jetty running in a new JVM:

Jetty continues to execute until you either:

  • Press in the terminal window to stop the plugin, which also stops the forked JVM (only if you started with )
  • Use to stop the forked JVM, which also stops the plugin.

Note

If you want to set a custom port for the Jetty connector you need to specify it in a file rather than setting the connector and port tags. You can specify the location of the using the parameter.

This goal is for use with an execution binding in your . It is similar to the goal, however it does NOT first execute the build up until the phase to ensure 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 .

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 scenarios for the Jetty plugin. You use the and Maven build phases to trigger the execution and termination of Jetty:

The stop goal stops a running instance of Jetty. To use it, you need to configure the plugin with a special port number and key. That same port number and key will also be used by the other goals that start jetty.

stopPort
A port number for Jetty to listen on to receive a stop command to cause it to shutdown.
stopKey
A string value sent to the to validate the stop command.
stopWait
The maximum time in seconds that the plugin will wait for confirmation that Jetty has stopped. If false or not specified, the plugin does not wait for confirmation but exits after issuing the stop command.

Here’s a configuration example:

Then, while Jetty is running (in another window), type:

The must be free on the machine you are running on. If this is not the case, you will get an "Address already in use" error message after the "Started ServerConnector …​" message.

This goal calculates a synthetic (the "effective web.xml") according to the rules of the Servlet Specification taking into account all sources of discoverable configuration of web components in your application: descriptors (, , ) and discovered annotations (, , ). Note that no programmatic declarations of servlets, filters and listeners can be taken into account. The effective from these combined sources is generated and displayed as maven log output. Other useful information about your webapp that is produced as part of the analysis is also stored as context parameters in the effective-web.xml. The effective-web.xml can be used in conjunction with the Quickstart feature to quickly start your webapp (note that Quickstart is not appropriate for the mvn jetty goals).

The following configuration parameters allow you to save the file:

deleteOnExit
By default this is . If set to , the effective web.xml is generated into a file called in the build directory.
effectiveWebXml
The full path name of a file into which you would like the effective web xml generated.

You can also generate the origin of each element into the effective web.xml file. The origin is either a descriptor eg web.xml,web-fragment.xml,override-web.xml file, or an annotation eg @WebServlet. Some examples of elements with origin attribute information are:

To generate origin informatino, use the following configuration parameters on the element:

originAttribute
The name of the attribute that will contain the origin. By default it is .
generateOrigin
False by default. If true, will force the generation of the originAttribute onto each element.

If your webapp depends on other war files, thejetty:run and jetty:run-forked goals are able to merge resources from all of them. It can do so based on the settings of the maven-war-plugin, or if your project does not use the maven-war-plugin to handle the overlays, it can fall back to a simple algorithm to determine the ordering of resources.

The maven-war-plugin has a rich set of capabilities for merging resources. The and goals are able to interpret most of them and apply them during execution of your unassembled webapp. This is probably best seen by looking at a concrete example.

Suppose your webapp depends on the following wars:

Containing:

They are configured for the maven-war-plugin:

Then executing jetty:run would yield the following ordering of resources: . Note that the current project’s resources are placed last in the ordering due to the empty <overlay/> element in the maven-war-plugin. You can either use that, or specify the parameter to the jetty-maven-plugin.

Moreover, due to the specified above, a request for the resource ` bar.jsp` would only be satisfied from Similarly as is excluded, a request for it would result in a 404 error.

The algorithm is fairly simple, is based on the ordering of declaration of the dependent wars, and does not support exclusions. The configuration parameter (see the section on Configuring Your Webapp for more information) can be used to control whether your webapp’s resources are placed first or last on the resource path at runtime.

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

Suppose the webapps contain:

Then our webapp has available these additional resources:

Configuring Security Settings

You can configure LoginServices in the plugin. Here’s an example of setting up the HashLoginService for a webapp:

Using Multiple Webapp Root Directories

If you have external resources that you want to incorporate in the execution of a webapp, but which are not assembled into war files, you can’t use the overlaid wars method described above, but you can tell Jetty the directories in which these external resources are located. At runtime, when Jetty receives a request for a resource, it searches all the locations to retrieve the resource. It’s a lot like the overlaid war situation, but without the war.

Here is a configuration example:

Running More than One Webapp

You can use either a file to configure extra (pre-compiled) webapps that you want to deploy, or you can use the configuration element to do so. If you want to deploy webapp A, and webapps B and C in the same Jetty instance:

Putting the configuration in webapp A’s :

Important

If the you are deploying is a webapp, it is essential that you use an instance rather than a standard instance. Only the former will allow the webapp to function correctly in the maven environment.

Alternatively, add a file to webapp A. Copy the file from the Jetty distribution, and then add WebAppContexts for the other 2 webapps:

Then configure the location of this 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.

Setting System Properties

You can specify property name/value pairs that Jetty sets as System properties for the execution of the plugin. This feature is useful to tidy up the command line and save a lot of typing.

However, sometimes it is not possible to use this feature to set System properties - sometimes the software component using the System property is already initialized by the time that maven runs (in which case you will need to provide the System property on the command line), or by the time that Jetty runs. In the latter case, you can use the maven properties plugin to define the system properties instead. Here’s an example that configures the logback logging system as the Jetty logger:

Note

If a System property is already set (for example, from the command line or by the JVM itself), then by default these configured properties DO NOT override them (see below for use of the <force> parameter).

Specifying System Properties in the POM

Here’s an example of how to specify System properties in the POM:

To change the default behavior so that these system properties override those on the command line, use the parameter:

Specifying System Properties in a File

You can also specify your System properties in a file. System properties you specify in this way do not override System properties that set on the command line, by the JVM, or directly in the POM via .

Suppose we have a file called which contains the following:

This can be configured on the plugin like so:

You can instead specify the file by setting the System property on the command line.

See an error or something missing? Contribute to this documentation at Github!(Generated: 2017-05-02)

Sours: https://portail.capsana.ca/doc/9.4.5.v20170502/jetty-maven-plugin.html
Note.png

If you're using the plugin with the EOL Jetty 6, see the Jetty 6 Maven Plugin guide at codehaus. It is called the jetty-maven-plugin. In previous versions it was the maven-jetty-plugin.

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.

Note.png

You will need to use maven 3 from jetty-7.5.3 release going forwards.

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

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:

Configuring Your WebApp

These configuration parameters apply to your webapp. They should apply to all goals, except for and :

  • <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 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
    • <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 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
  • classes in
  • in

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 and 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-zero 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, so 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:

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 ensure 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 scenarios for the Jetty plugin and use the configuration option to force Jetty to execute only while Maven is running, instead of running indefinitely. You use the and 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>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 you need to configure the plugin with a special port number and key that you also supply by executing the 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 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

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

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><loginServiceimplementation="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><connectorimplementation="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><baseResourceimplementation="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>
Note.png
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 the 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:

<plugin><groupId>org.mortbay.jetty</groupId><artifactId>jetty-maven-plugin</artifactId><configuration><scanIntervalSeconds>10</scanIntervalSeconds><webApp><contextPath>/test</contextPath></webApp><contextHandlers><contextHandlerimplementation="org.eclipse.jetty.webapp.WebAppContext"><war>${basedir}../../B.war</war><contextPath>/B</contextPath></contextHandler><contextHandlerimplementation="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:

<Refid="Contexts"><Callname="addHandler"><Arg><Newclass="org.eclipse.jetty.webapp.WebAppContext"><Setname="contextPath">/B</Set><Setname="war">../../B.war</Set></New></Arg></Call><Call><Arg><Newclass="org.eclipse.jetty.webapp.WebAppContext"><Setname="contextPath">/C</Set><Setname="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 values 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:

<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's an 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:

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>
Sours: https://wiki.eclipse.org/Jetty/Feature/Jetty_Maven_Plugin
  1. Totally free tarot readings
  2. The show piano chords
  3. Mazda newport news va

Rapid Testing Using the Jetty Plugin

Normally, testing a web application involves compiling Java sources, creating a WAR and deploying it to a web container.

Using the Jetty Plugin enables you to quickly test your web application by skipping the last two steps. By default the Jetty Plugin scans for any changes in your Java sources and for changes to your web sources. The Jetty Plugin will automatically reload the modified classes and web sources.

To use the Jetty Plugin just add the following in your :

<project> ... <build> <plugins> <plugin> <groupId>org.mortbay.jetty</groupId> <artifactId>maven-jetty-plugin</artifactId> <version>6.1.10</version> <configuration> <scanIntervalSeconds>10</scanIntervalSeconds> <connectors> <connector implementation="org.mortbay.jetty.nio.SelectChannelConnector"> <port>8080</port> <maxIdleTime>60000</maxIdleTime> </connector> </connectors> </configuration> </plugin> ... </plugins> </build> ... </project>

Then start Jetty:

The command will block with Jetty listening on port 8080.

Check the Jetty Plugin documentation for more details.

Sours: https://maven.apache.org/plugins/maven-war-plugin/examples/rapid-testing-jetty6-plugin.html

Configuring the Jetty Maven Plugin

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 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.

Important

You should use Maven 3.3+ for this plugin.

While the Jetty Maven Plugin can be very useful for development we do not recommend its use in a production capacity. In order for the plugin to work it needs to leverage many internal Maven apis and Maven itself it not a production deployment tool. We recommend either the traditional distribution deployment approach or using embedded Jetty.

Quick Start: Get Up and Running

First, add to your definition:

Then, from the same directory as your root , type:

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 If you save changes and recompile your class files, Jetty redeploys your webapp, and you can instantly test the changes that were just made.

You can terminate the plugin with a in the terminal window where it is running.

Note

The classpath of the running Jetty instance and its deployed webapp are managed by Maven, and may not be exactly what you expect. For example: a webapp’s dependent jars might be referenced via the local repository, not the directory.

The Jetty Maven plugin has a number of distinct Maven goals. Arguably the most useful is the goal which runs Jetty on an unassembled webapp. There are other goals which help you accomplish different tasks. For example, you might need to run your webapp in a forked instance of Jetty rather than within the process running Maven; or you may need finer grained control over the maven lifecycle stage in which you wish to deploy your webapp. There are different goals to accomplish these tasks, as well as several others.

To see a list of all goals supported by the Jetty Maven plugin, do:

To see the detailed list of parameters that can be configured for a particular goal, in addition to its description, do:

mvn jetty:help -Ddetail=true -Dgoal= <goal name>

Configuring the Jetty Container

These configuration elements set up the Jetty environment in which your webapp executes. They are common to most goals:

httpConnector

Optional. If not specified, Jetty will create a ServerConnector instance listening on port 8080. You can change this default port number by using the system property on the command line, for example, . Alternatively, you can use this configuration element to set up the information for the ServerConnector. The following are the valid configuration sub-elements:

jettyXml
Optional. A comma separated list of locations of Jetty xml files to apply in addition to any plugin configuration parameters. You might use it if you have other webapps, handlers, specific types of connectors etc., to deploy, or if you have other Jetty objects that you cannot configure from the plugin.
scanIntervalSeconds
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.
reload
Default value is "automatic", used in conjunction with a non-zero `scanIntervalSeconds` causes automatic hot redeploy when changes are detected. Set to "manual" instead to trigger scanning by typing a linefeed in the console running the plugin. This might be useful when you are doing a series of changes that you want to ignore until you’re done. In that use, use the parameter.
dumpOnStart
Optional. Default value is false. If true, then jetty will dump out the server structure on start.
loginServices
Optional. A list of implementations. Note that there is no default realm. If you use a realm in your 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 parameter.
requestLog

Optional. An implementation of the request log interface. An implementation that respects the NCSA format is available as . There are three other ways to configure the RequestLog:

  • In a jetty xml config file, as specified in the parameter.
  • In a context xml config file, as specified in the parameter.
  • In the element.

See Configuring Request Logs for more information.

server
Optional as of Jetty 9.3.1. This would configure an instance of the for the plugin to use, however it is usually NOT necessary to configure this, as the plugin will automatically configure one for you. In particular, if you use the jettyXml element, then you generally DON’T want to define this element, as you are probably using the jettyXml file to configure up a Server with a special constructor argument, such as a custom threadpool. If you define both a server element AND use a jetty xml element which points to a config file that has a line like then the the xml configuration will override what you configure for the server in the .
stopPort
Optional. Port to listen on for stop commands. Useful to use in conjunction with the stop or run-forked goals.
stopKey
Optional. Used in conjunction with stopPort for stopping jetty. Useful when used in conjunction with the stop or run-forked goals.
systemProperties
Optional. Allows 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. By default, 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 . Read Setting System Properties for how to force overrides.
skip
Default is false. If true, the execution of the plugin exits. Same as setting the SystemProperty on the command line. This is most useful when configuring Jetty for execution during integration testing and you want to skip the tests.
useProvidedScope
Default value is . If true, the dependencies with are placed onto the container classpath. Be aware that this is 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 instead.
excludedGoals
Optional. A list of Jetty plugin goal names that will cause the plugin to print an informative message and exit. Useful if you want to prevent users from executing goals that you know cannot work with your project.

Configuring a Https Connector

In order to configure an HTTPS connector, you need to use jetty xml configuration files. This example uses files copied directly from the jetty distribution etc/ directory, although you can of course make up your own xml file or files. We will use the following files:

jetty.xml

Sets up various characteristics of the instance for the plugin to use. Importantly, it sets up the element that we can refer to in subsequent xml files that configure the connectors. Below is the relevant section taken from jetty.xml.

jetty-ssl.xml

Sets up ssl which will be used by the https connector. Here’s the file from the jetty-distribution:

jetty-https.xml

Set up the https connector using the HttpConfiguration from and the ssl configuration from :

Now you need to let the plugin know to apply the files above:

Caution

Just as with an installed distribution of Jetty, the ordering of the xml files is significant.

You can also use Jetty xml files to configure a http connector for the plugin to use. Here we use the same file from the Jetty distribution:

Now we add it to the list of configs for the plugin to apply:

Alternatively, you can use the httpConnector configuration element inside the pom instead as described above.

These configuration parameters apply to your webapp. They are common to almost all goals.

webApp

This is an instance of org.eclipse.jetty.maven.plugin.JettyWebAppContext, which is an extension to the class . You can use any of the setter methods on this object 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 . If using a custom value for this parameter, you probably want to include the leading , example .
descriptor
The path to the file for your webapp.
defaultsDescriptor
The path to a file that will be applied to your webapp before the . If you don’t supply one, Jetty uses a default file baked into the .
overrideDescriptor
The path to a file that Jetty applies after reading your . 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 .
baseResource
The path from which Jetty serves static resources. Defaults to .
resourceBases
Use instead of if you have multiple directories from which you want to serve static content. This is an array of directory names.
baseAppFirst
Defaults to "true". Controls whether any overlaid wars are added before or after the original base resource(s) of the webapp. See the section on overlaid wars for more information.
containerIncludeJarPattern
Defaults to . This is a pattern that is applied to the names of the jars on the container’s classpath (ie the classpath of the plugin, not that of the webapp) that should be scanned for fragments, tlds, annotations etc. This is analogous to the context attribute org.eclipse.jetty.server.webapp.ContainerIncludeJarPattern that is documented here. You can define extra patterns of jars that will be included in the scan.
webInfIncludeJarPattern
Defaults to matching all of the dependency jars for the webapp (ie the equivalent of WEB-INF/lib). You can make this pattern more restrictive to only match certain jars by using this setter. This is analogous to the context attribute org.eclipse.jetty.server.webapp.WebInfIncludeJarPattern that is documented here.
contextXml
The path to a context xml file that is applied to your webapp AFTER the element.

The goal runs on a webapp that does not have to be built into a WAR. Instead, Jetty deploys the webapp from its 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
  • classes in
  • in

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.

You do not need to assemble the webapp 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.

Note

As of Jetty 9.4.7, when using jetty:run in a multi-module build, it is no longer necessary to build each of the modules that form dependencies of the webapp first. Thus, if your webapp depends on other modules in your project and they are present in the reactor at the same time, jetty will use their compiled classes rather than their jar files from your local maven repository.

Here is an example, which turns on scanning for changes every ten seconds, and sets the webapp context path to :

In addition to the element that is common to most goals, the goal supports:

classesDirectory
Location of your compiled classes for the webapp. You should rarely need to set this parameter. Instead, you should set in your .
testClassesDirectory
Location of the compiled test classes for your webapp. By default this is .
useTestScope
If true, the classes from and dependencies of scope "test" are placed first on the classpath. By default this is false.
webAppSourceDirectory
By default, this is set to . If your static sources are in a different location, set this parameter accordingly.
jettyEnvXml
Optional. Location of a file, which allows you to make JNDI bindings that satisfy , , and linkages in the 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 the plugin automatically scans.
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 of , each consisting of a directory, and including and/or excluding parameters to specify the file matching patterns.
scanClassesPattern
Since 9.3.0. Optional. Include and exclude patterns that can be applied to the classesDirectory for the purposes of scanning, it does not affect the classpath. If a file or directory is excluded by the patterns then a change in that file (or subtree in the case of a directory) is ignored and will not cause the webapp to redeploy. Patterns are specified as a relative path using a glob-like syntax as described in the javadoc for FileSystem.getPathMatcher.
scanTestClassesPattern
Since 9.3.0. Optional. Include and exclude patterns that can be applied to the testClassesDirectory for the purposes of scanning, it does not affect the classpath. If a file or directory is excluded by the patterns then a change in that file (or subtree in the case of a directory) is ignored and will not cause the webapp to redeploy. Patterns are specified as a relative path using a glob-like syntax as described in the javadoc for FileSystem.getPathMatcher.

Here’s an example:

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

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

war
The location of the built WAR file. This defaults to . If this is not sufficient, set it to your custom location.

Here’s how to set it:

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 , Jetty watches your , and for changes and redeploys when necessary.

war
The location of the exploded WAR. This defaults to , but you can override the default by setting this parameter.

Here’s how to set it:

This is basically the same as , but without assembling the WAR of the current module - you can nominate the location of any war to run. Unlike , the phase in which this plugin executes is not bound to the "package" phase - you may bind it to any phase to use it.

war
The location of the WAR file. This defaults to , but you can override the default by setting this parameter.
daemon
If true, this plugin will start Jetty but let the build continue. This is useful if you want to start jetty as an execution binding in a particular phase and then stop it in another. Alternatively, you can set this parameter to false, in which case Jetty will block and you will need to use a ctrl-c to stop it.

Here’s the configuration:

This goal allows you to start the webapp in a new JVM, optionally passing arguments to that new JVM. This goal supports mostly the same configuration parameters as the goal with a couple of extras to help configure the forked process. Unlike the goal, the goal will not scan the webapp for changes and redeploy.

The available configuration parameters - in addition to those for the goal - are:

jvmArgs
Optional. A string representing arbitrary arguments to pass to the forked JVM.
env
Optional. Map of key/value pairs to pass as environment to the forked JVM.
waitForChild
Default is . This causes the parent process to wait for the forked process to exit. In this case you can use to terminate both processes. It is more useful to set it to , in which case the parent process terminates whilst leaving the child process running. You use the goal to stop the child process. In the case where is , the output from the child process is written to .
maxChildChecks
Default is . This is maximum number of times the parent process checks to see if the child process has started. Only relevant if is .
maxChildCheckInterval
Default is . This is the time in milliseconds between checks to see if the child process has started. Only relevant if is .
forkWebXml
Default is . This is the name of the file into which jetty generates the effective web.xml for use by the child process.
javaPath
Default will be your This the java executable used to start the child process

The following parameters are NOT applicable:

  • scanTargets
  • scanTargetPatterns
  • scanClassesPattern
  • scanTestClassesPattern

Some of the container configuration parameters are NOT available with this goal:

scanIntervalSeconds
Not supported. The forked jetty will not monitor and redeploy the webapp.
reload
Not supported. The forked jetty will not redeploy the webapp.
httpConnector
Not supported. To define custom connectors use a jetty xml file instead.
loginServices
Not supported. To define LoginServices use a jetty xml or context xml file instead.
requestLog
Not supported. To define a RequestLog setup, use a jetty xml or context xml file instead.
systemProperties
Not supported. Use the parameter to pass system properties to the forked process.

To deploy your unassembled web app to Jetty running in a new JVM:

Jetty continues to execute until you either:

  • Press in the terminal window to stop the plugin, which also stops the forked JVM (only if you started with )
  • Use to stop the forked JVM, which also stops the plugin.

Note

If you want to set a custom port for the Jetty connector you need to specify it in a file rather than setting the connector and port tags. You can specify the location of the using the parameter.

Introduced in Jetty 9.4.8, this goal allows you to execute your unassembled webapp in a local distribution of Jetty. This can be useful if your webapp requires a highly customized environment in which to run. If your webapp is designed to run in the jetty distribution in production, then this goal is the closest approximation to that environment.

Similar to the goal, this goal will fork a child process in which to execute your webapp in the distro.

The configuration parameters are mostly the same as the goal (although see below for some exceptions), with the addition of:

jettyBase
Optional. The location of an existing jetty base directory to use to deploy the webapp. The existing base will be copied to the directory before the webapp is deployed. If there is no existing jetty base, a fresh one will be made in .
jettyHome
Optional. The location of an existing unpacked jetty distribution. If one does not exist, a fresh jetty distribution will be downloaded from maven and installed to the directory.
jettyProperties
Optional. An array of jetty properties to specify on the command line for the child process.
jvmArgs
Optional. A string representing arguments that should be passed to the jvm of the child process.
modules
Optional. An array of names of jetty modules that the jetty child process will activate.
waitForChild
Default is . Like jetty:run-forked, if , the parent process will wait for the child to exit and echo all of its output to the parent’s stdout/stderr. In that case you can terminate both processes with a . If , the parent does not wait for the child to finish, and the child will write all of its output to . To stop the asynchronously executing child process you can use .
maxChildChecks
Default value 10. This is the maximum number of times the parent will check to see if the child started correctly when is .
maxChildCheckInterval
Default value 100. This is the interval in milliseconds between checks to see if the child started correctly. Only applicable if is .
javaPath
Default will be your This the java executable used to start the child process

Note

Use the parameter to configure the Jetty distribution appropriately rather than using jetty artifacts as .

The following parameters are NOT applicable to this goal:

  • scanTargets
  • scanTargetPatterns
  • scanClassesPattern
  • scanTestClassesPattern

The following container configuration options are NOT applicable for this goal:

scanIntervalSeconds
Not supported. This goal will not monitor and redeploy the webapp.
reload
Not supported. This goal will not redeploy the webapp.
httpConnector
Not supported. Use the parameter to enable appropriate modules, or the parameter to point to an appropriately configured jetty base.
loginServices
Not supported. Use the parameter to enable appropriate modules, or the parameter to point to an appropriately configured jetty base.
requestLog
Not supported. Use the parameter to enable appropriate modules, or the parameter to point to an appropriately configured jetty base.
systemProperties
Not supported. Use the parameter to pass system properties to the forked process.

Here’s an example of using the configuration parameters:

Note

When defining modules for this goal, use the standard Jetty module names and not the name of the related Jetty sub-project. For example, in the configuration above support for JMX is configured by adding the Jetty module and not the sub-project.

To deploy your unassembled web app to jetty running as a local distribution:

This goal is for use with an execution binding in your . It is similar to the goal, however it does NOT first execute the build up until the phase to ensure 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 .

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 scenarios for the Jetty plugin. You use the and Maven build phases to trigger the execution and termination of Jetty:

The stop goal stops a running instance of Jetty. To use it, you need to configure the plugin with a special port number and key. That same port number and key will also be used by the other goals that start jetty.

stopPort
A port number for Jetty to listen on to receive a stop command to cause it to shutdown.
stopKey
A string value sent to the to validate the stop command.
stopWait
The maximum time in seconds that the plugin will wait for confirmation that Jetty has stopped. If false or not specified, the plugin does not wait for confirmation but exits after issuing the stop command.

Here’s a configuration example:

Then, while Jetty is running (in another window), type:

The must be free on the machine you are running on. If this is not the case, you will get an "Address already in use" error message after the "Started ServerConnector …​" message.

This goal calculates a synthetic (the "effective web.xml") according to the rules of the Servlet Specification taking into account all sources of discoverable configuration of web components in your application: descriptors (, , ) and discovered annotations (, , ). Note that no programmatic declarations of servlets, filters and listeners can be taken into account. The effective from these combined sources is generated and displayed as maven log output. Other useful information about your webapp that is produced as part of the analysis is also stored as context parameters in the effective-web.xml. The effective-web.xml can be used in conjunction with the Quickstart feature to quickly start your webapp (note that Quickstart is not appropriate for the mvn jetty goals).

The following configuration parameters allow you to save the file:

deleteOnExit
By default this is . If set to , the effective web.xml is generated into a file called in the build directory.
effectiveWebXml
The full path name of a file into which you would like the effective web xml generated.

You can also generate the origin of each element into the effective web.xml file. The origin is either a descriptor eg web.xml,web-fragment.xml,override-web.xml file, or an annotation eg @WebServlet. Some examples of elements with origin attribute information are:

To generate origin information, use the following configuration parameters on the element:

originAttribute
The name of the attribute that will contain the origin. By default it is .
generateOrigin
False by default. If true, will force the generation of the originAttribute onto each element.

If your webapp depends on other war files, the jetty:run and jetty:run-forked goals are able to merge resources from all of them. It can do so based on the settings of the maven-war-plugin, or if your project does not use the maven-war-plugin to handle the overlays, it can fall back to a simple algorithm to determine the ordering of resources.

The maven-war-plugin has a rich set of capabilities for merging resources. The and goals are able to interpret most of them and apply them during execution of your unassembled webapp. This is probably best seen by looking at a concrete example.

Suppose your webapp depends on the following wars:

Containing:

They are configured for the maven-war-plugin:

Then executing jetty:run would yield the following ordering of resources: . Note that the current project’s resources are placed last in the ordering due to the empty <overlay/> element in the maven-war-plugin. You can either use that, or specify the parameter to the jetty-maven-plugin.

Moreover, due to the specified above, a request for the resource ` bar.jsp` would only be satisfied from Similarly as is excluded, a request for it would result in a 404 error.

The algorithm is fairly simple, is based on the ordering of declaration of the dependent wars, and does not support exclusions. The configuration parameter (see the section on Configuring Your Webapp for more information) can be used to control whether your webapp’s resources are placed first or last on the resource path at runtime.

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

Suppose the webapps contain:

Then our webapp has available these additional resources:

Configuring Security Settings

You can configure LoginServices in the plugin. Here’s an example of setting up the HashLoginService for a webapp:

Using Multiple Webapp Root Directories

If you have external resources that you want to incorporate in the execution of a webapp, but which are not assembled into war files, you can’t use the overlaid wars method described above, but you can tell Jetty the directories in which these external resources are located. At runtime, when Jetty receives a request for a resource, it searches all the locations to retrieve the resource. It’s a lot like the overlaid war situation, but without the war.

Here is a configuration example:

Running More than One Webapp

You can use either a file to configure extra (pre-compiled) webapps that you want to deploy, or you can use the configuration element to do so. If you want to deploy webapp A, and webapps B and C in the same Jetty instance:

Putting the configuration in webapp A’s :

Important

If the you are deploying is a webapp, it is essential that you use an instance rather than a standard instance. Only the former will allow the webapp to function correctly in the maven environment.

Alternatively, add a file to webapp A. Copy the file from the Jetty distribution, and then add WebAppContexts for the other 2 webapps:

Then configure the location of this 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.

Simply configure a jetty base that contains all of the other prebuilt webapps you wish to deploy.

Setting System Properties

You can specify property name/value pairs that Jetty sets as System properties for the execution of the plugin. This feature is useful to tidy up the command line and save a lot of typing.

However, sometimes it is not possible to use this feature to set System properties - sometimes the software component using the System property is already initialized by the time that maven runs (in which case you will need to provide the System property on the command line), or by the time that Jetty runs. In the latter case, you can use the maven properties plugin to define the system properties instead. Here’s an example that configures the logback logging system as the Jetty logger:

Note

If a System property is already set (for example, from the command line or by the JVM itself), then by default these configured properties DO NOT override them (see below for use of the <force> parameter).

Specifying System Properties in the POM

Here’s an example of how to specify System properties in the POM:

To change the default behavior so that these system properties override those on the command line, use the parameter:

Specifying System Properties in a File

You can also specify your System properties in a file. System properties you specify in this way do not override System properties that set on the command line, by the JVM, or directly in the POM via .

Suppose we have a file called which contains the following:

This can be configured on the plugin like so:

You can instead specify the file by setting the System property on the command line.

See an error or something missing? Contribute to this documentation at Github!(Generated: 2019-11-20)

Sours: https://xy2401.com/local-docs/java/jetty.9.4.24.v20191120/jetty-maven-plugin.html

Plugin maven jetty

<projectxmlns="http://maven.apache.org/POM/4.0.0"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>org.eclipse.jetty.demo</groupId> <artifactId>webapp-2.5</artifactId> <packaging>war</packaging> <version>1.0-SNAPSHOT</version> <name>webapp-2.5 Maven Webapp</name> <prerequisites> <maven>3.0.5</maven> </prerequisites> <properties> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> <jetty-version>7.6.14.v20131031</jetty-version> <slf4j-version>1.7.5</slf4j-version> <logback-version>1.2.0</logback-version> </properties> <dependencies> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.13.1</version> <scope>test</scope> </dependency> <dependency> <groupId>javax.servlet</groupId> <artifactId>servlet-api</artifactId> <version>2.5</version> <scope>provided</scope> </dependency> </dependencies> <build> <finalName>webapp-2.5</finalName> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>3.1</version> <configuration> <source>1.5</source> <target>1.5</target> </configuration> </plugin> <plugin> <groupId>org.mortbay.jetty</groupId> <artifactId>jetty-maven-plugin</artifactId> <version>7.6.14.v20131031</version> <configuration> <jettyXml>src/main/etc/jetty.xml</jettyXml> <scanIntervalSeconds>10</scanIntervalSeconds> <stopKey>STOP</stopKey> <stopPort>9999</stopPort> <webApp> <contextPath>/</contextPath> </webApp> <connectors> <connectorimplementation="org.eclipse.jetty.server.nio.SelectChannelConnector"> <port>28080</port> <maxIdleTime>60000</maxIdleTime> </connector> </connectors> </configuration> <dependencies> <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-api</artifactId> <version>${slf4j-version}</version> </dependency> <dependency> <groupId>ch.qos.logback</groupId> <artifactId>logback-classic</artifactId> <version>${logback-version}</version> </dependency> <dependency> <groupId>org.eclipse.jetty</groupId> <artifactId>jetty-jsp</artifactId> <version>${jetty-version}</version> </dependency> </dependencies> <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> </plugins> </build></project>
Sours: https://github.com/jetty-project/jetty-maven-plugin-examples/blob/master/webapp-2.5/pom.xml
Java Maven Web Application Project Deploy-- How to run the maven web app in an embedded jetty server

How to add Maven Jetty Plugin

Jetty is a Java Web Server which was developed by the Eclipse Foundation. Maven Jetty Plugin allows you to test, debug, and deploy your web application without setting up a server. This article will show you how to add Maven Jetty Plugin in your project.

Adding Jetty Plugin to your pom.xml

Visit this post to create a simple maven web application if you don’t have one. In your pom.xml, add the jetty plugin in the build > plugins section.

<build> <!-- other stuffs inside your build section--> <plugins> <!-- Jetty Plugin. Default port is 8080 --> <plugin> <groupId>org.eclipse.jetty</groupId> <artifactId>jetty-maven-plugin</artifactId> <version>9.4.28.v20200408</version> </plugin> </plugins> </build>

You can change the default port of 8080 to something you want to avoid any conflicting port if you are running multiple instances of Jetty. Or add a hot-swap functionality that auto reloads Jetty to deploy the changed file.

For example, here’s our configuration that changes the port from 8080 to 8085 and scans the project every 5 seconds for any changes:

<build> <!-- other stuffs inside your build section--> <plugins> <!-- Jetty Plugin. Default port is 8080 --> <plugin> <groupId>org.eclipse.jetty</groupId> <artifactId>jetty-maven-plugin</artifactId> <version>9.4.28.v20200408</version> <configuration> <httpConnector> <port>8085</port> </httpConnector> <!-- scans your project for any changes to hot swap it to server --> <scanIntervalSeconds>5</scanIntervalSeconds> </configuration> </plugin> </plugins> </build>

Starting Jetty Plugin

Using IntelliJ, you can run jetty plugin by expanding the Maven Tab and on Plugins section, double click jetty:run.

If you want to start jetty in the command line, navigate to your root project (where your pom.xml resides) and type:

mvn jetty:run
jetty

Test it to your browser by going to localhot:8080 or 8085 or to the port that you have defined.

Other developers encountered an issue wherein IntelliJ is not showing the Jetty plugin in the Maven tab. It might be because you have added the Jetty plugin under the PluginManagement section. To resolve this, move the jetty plugin outside and just add it as a child in build > plugins section.

Share this tutorial!

Sours: https://javapointers.com/how-to/add-maven-jetty-plugin/

Similar news:

Does it hurt, Anechka?" Mom asked. Very unpleasant, "was the answer. Yes, daughter, there is little pleasant here, but you have to be patient until I check everything. " She began to twist her finger around its axis, with my left hand at the same time I feel the girl's belly from below.the daughter began to object.



2407 2408 2409 2410 2411