Being able to run the jetty maven plugin on your webapp – but in a freshly forked jvm – is a feature that has been requested for a loooong time. With jetty-7.5.2 release, this feature has been implemented, and it even works on your unassembled webapp.

How to Run


mvn jetty:run-forked

That will kick off a Jetty instance in a brand new jvm and deploy your unassemabled webapp to it. The forked Jetty will keep on running until either:

  • you execute a mvn jetty:stop (in another terminal window)
  • you <cntrl-c> the plugin

The plugin will keep on executing until either:

  • you stop it with a <cntrl-c>
  • the forked jvm terminates

NOTE: I’m interested in obtaining feedback about the lifecycles of the plugin and the forked Jetty. Is the lifecycle linkage that I’ve implemented the way you want to use it? Do you want the forked jvm to continue on, even if the plugin exits? Please post your input to the Jetty list at jetty-users@eclipse.org.

How to Configure

You need a few different configuration parameters from the usual jetty:run ones. Let’s look at an example:

     <plugin>
        <groupId>org.mortbay.jetty</groupId>
        <artifactId>jetty-maven-plugin</artifactId>
        <version>7.5.2.v20111006</version>
        <configuration>
          <stopPort>8087</stopPort>
          <stopKey>foo</stopKey>
          <jettyXml>src/main/config/jetty.xml</jetty.xml>
          <contextXml>src/main/config/context.xml</jetty.xml>
          <contextPath>/foo</contextPath>
          <tmpDirectory>${project.build.directory}/tmp</tmpDirectory>
          <jvmArgs>-verbose:gc -Xmx80m</jvmArgs>
        </configuration>
      </plugin>

You need to specify the stopKey and stopPort so that you can control the forked Jetty using the handy maven goal mvn jetty:stop.
You can use the jettyXml parameter to specify a comma separated list of jetty xml configuration files that you can use to configure the container. There’s nothing special about these config files, they’re just normal jetty configuration files. You can also use this parameter with the jetty:run goal too.
The contextXml parameter specifies the location of a webapp context xml configuration file. Again, this is a normal jetty context xml configuration file. You can also use this with the jetty:run goal too, either in conjunction with, or instead of, the <webAppConfig> parameter (which configures the webapp right there in the pom). As the jetty:run-forked goal does NOT support the <webAppConfig> element, you MUST use contextXml if you need to configure the webapp.
The contextPath parameter specifies the context path at which to deploy the webapp. You can use this as a simple shortcut instead of the contextXml parameter if you have no other configuration that you need to do for the webapp. Or, you can specify both this AND the contextXml parameter, in which case the contextPath takes precedence over the context path inside the context xml file.
tmpDirectory is the location of a temporary working directory for the webapp. You can configure it either here, or in a contextXml file. If specified in both places, the tmpDirectory takes precedence.
With the jvmArgs parameter, you can specify an arbitrary list of args that will be passed as-is to the newly forked jvm.
There’s also the same parameters as the mvn jetty:run goal:

  • skip – if true the execution of the plugin is skipped
  • useTestScope – if true, jars of <scope>test</scope> and the test classes are placed on the webapp’s classpath inside the forked jvm
  • useProvidedScope – if true, jars of <scope>provided</scope> are placed on the container’s classpath inside the forked jvm
  • classesDirectory – the location of the classes for the webapp
  • testClassesDirectory – the location of the test classes
  • webAppSourceDirectory – the location of the static resources for the webapp

Also, just like the mvn jetty:run case, if you have dependencies that are <type>war</type> , then their resources will be overlaid onto the webapp when it is deployed in the new jvm.


7 Comments

Tommy · 19/10/2011 at 18:26

Looks good!
Will run-forked support for auto reloading of new class files?

    janb · 19/10/2011 at 23:16

    Hi Tommy,
    No, at the moment it will not auto-reload. If this is a feature you would find useful, please open a jira enhancement request for it: http://jira.codehaus.org/browse/Jetty. The more votes on the issue, the more likely it would to be implemented.
    cheers
    Jan

theTestTube · 12/06/2012 at 07:12

Hi!
Nice trick but it’s not working in our case 🙁
With,
org.mortbay.jetty
jetty-maven-plugin
7.6.4.v20120524
true
${my.jetty.stop.port}
${my.jetty.stop.challenge}
.
${my.staging.path}/code/lib/myFirst.war
${my.first.context.path}
${my.conf.path}/web-node0.xml
${my.staging.path}/code/lib/mySecond.war
${my.second.context.path}
${my.conf.path}
${my.conf.path}/jetty-jmx.xml,${my.conf.path}/jetty-handler.xml,${my.conf.path}/jetty-nio.xml,${my.conf.path}/jetty-ssl.xml
launched with “mvn jetty:run-forked”, child process is effectively created but Maven 3.0.4 process waits undefinitelly until Ctrl-C is pressed or stopPort used.
Should I open an issue?
Merci.-

theTestTube · 12/06/2012 at 07:15

Hi!
Nice trick but it’s not working in our case 🙁 . With,

<plugin>
<groupId>org.mortbay.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<version>7.6.4.v20120524</version>
<configuration>
<daemon>true</daemon>
<stopPort>${my.jetty.stop.port}</stopPort>
<stopKey>${my.jetty.stop.challenge}</stopKey>
<webAppSourceDirectory>.</webAppSourceDirectory>
<contextHandlers>
<contextHandler implementation="org.mortbay.jetty.plugin.JettyWebAppContext">
<war>${my.staging.path}/code/lib/myFirst.war</war>
<contextPath>${my.first.context.path}</contextPath>
<overrideDescriptor>${my.conf.path}/web-node0.xml
</overrideDescriptor>
</contextHandler>
<contextHandler implementation="org.eclipse.jetty.webapp.WebAppContext">
<war>${my.staging.path}/code/lib/mySecond.war</war>
<contextPath>${my.second.context.path}</contextPath>
<extraClasspath>${my.conf.path}</extraClasspath>
</contextHandler>
</contextHandlers>
<jettyXml>${my.conf.path}/jetty-jmx.xml,${my.conf.path}/jetty-handler.xml,${my.conf.path}/jetty-nio.xml,${my.conf.path}/jetty-ssl.xml</jettyXml>
</configuration>
</plugin>

launched with “mvn jetty:run-forked”, child process is effectively created but Maven 3.0.4 process waits undefinitelly until Ctrl-C is pressed or stopPort used.
Should I open an issue?
Merci.-

    theTestTube · 01/08/2012 at 14:55

    We’re happy that jetty-7.6.5.v20120716 release added to control behaviour of jetty:run-forked.
    We’ve tested it and works properly with a configuration such as,

    ${my.xml.collection}
    ${project.build.directory}/webapp
    ${my.context.path}
    WEB-INF/web.xml
    WEB-INF/classes
    ${project.build.directory}/tmp
    ${my.stop.port}
    ${my.stop.challenge}
    ${my.jvm.args}
    false

    A notice for Jenkins processes running jetty:run-forked, take into account that ProcessKiller will kill your forked process by default. Our workaround for this is starting Jenkins nodes with -Dhudson.util.ProcessTree.disable=true" argument.

Greg Wilkins: mvn jetty:run-forked · 18/10/2011 at 14:45

[…] Read the original post: Greg Wilkins: mvn jetty:run-forked […]

Mvn jetty:run-forked | Eclipse | Syngu · 19/10/2011 at 05:33

[…] Being able to run the jetty maven plugin on your webapp – but in a freshly forked jvm – is a feature that has been requested for a loooong time. With jetty-7.5.2 release, this feature has been implemented, and it even works on your unassembled webapp.How to Run mvn jetty:run-forked That will kick off a Jetty instance in a brand new jvm and deploy your unassemabled webapp to it. The forked Jetty will keep on running until either: you execute a mvn jetty:stop (in another terminal window) you the plugin The plugin will keep on executing until either: you stop it with a the forked jvm terminates NOTE: I’m interested in obtaining feedback about the lifecycles of the plugin and the forked Jetty. Is the lifecycle linkage that I’ve implemented the way you want to use it? Do you want the forked jvm to continue on, even if the plugin exits? Please post your input to the Jetty list at jetty-users@eclipse.org.How to ConfigureYou need a few different configuration parameters from the usual jetty:run ones. Let’s look at an example: org.mortbay.jetty jetty-maven-plugin 7.5.2.v20111006 8087 foo src/main/config/jetty.xml src/main/config/context.xml /foo ${project.build.directory}/tmp -verbose:gc -Xmx80m You need to specify the stopKey and stopPort so that you can control the forked Jetty using the handy maven goal mvn jetty:stop.You can use the jettyXml parameter to specify a comma separated list of jetty xml configuration files that you can use to configure the container. There’s nothing special about these config files, they’re just normal jetty configuration files. You can also use this parameter with the jetty:run goal too.The contextXml parameter specifies the location of a webapp context xml configuration file. Again, this is a normal jetty context xml configuration file. You can also use this with the jetty:run goal too, either in conjunction with, or instead of, the parameter (which configures the webapp right there in the pom). As the jetty:run-forked goal does NOT support the element, you MUST use contextXml if you need to configure the webapp.The contextPath parameter specifies the context path at which to deploy the webapp. You can use this as a simple shortcut instead of the contextXml parameter if you have no other configuration that you need to do for the webapp. Or, you can specify both this AND the contextXml parameter, in which case the contextPath takes precedence over the context path inside the context xml file.tmpDirectory is the location of a temporary working directory for the webapp. You can configure it either here, or in a contextXml file. If specified in both places, the tmpDirectory takes precedence.With the jvmArgs parameter, you can specify an arbitrary list of args that will be passed as-is to the newly forked jvm. There’s also the same parameters as the mvn jetty:run goal:skip – if true the execution of the plugin is skippeduseTestScope – if true, jars of test and the test classes are placed on the webapp’s classpath inside the forked jvmuseProvidedScope – if true, jars of provided are placed on the container’s classpath inside the forked jvmclassesDirectory – the location of the classes for the webapptestClassesDirectory – the location of the test classeswebAppSourceDirectory – the location of the static resources for the webappAlso, just like the mvn jetty:run case, if you have dependencies that are war , then their resources will be overlaid onto the webapp when it is deployed in the new jvm.  Eclipse Read the full post on Planet Eclipse… […]

Comments are closed.