Maven: How to use jetty:run in a multi-module Maven project, without needing to install

jettymaven-2maven-jetty-pluginmaven-plugin

I'm new to Maven. I have a multi-module maven 2 project that has the following structure (somewhat simplified):

Project (POM packaging)
  |
  +-- Module1 (JAR)
  |     |
  |     +-- src
  |          |
  |          +-- main
  |               |
  |               +-- java
  |               +-- resources
  |
  +-- Module2 (JAR)
  |      |
  |     ...
  |
  +-- Web Module (WAR)
         |
        ...

I've configured the Web Module to include the Maven Jetty plugin.
This works great for building the production artifacts. For development, I discovered that I need to call mvn install on any module that I change, followed by stoping jetty and calling jetty:run again.
It would be much more productive if there was a way for the plugin to pick changes directly from each module's target directories. According to the jetty plugin documentation there seems to be such a feature, but it appears this only applies to the WAR module.
Even more important to me is to be able to make changes to resource files, without the need to restart jetty. That's because most of the resources are HTML template files, and it's enormously more productive to design and update the templates during development without needing to restart to see the changes.

So, is there a way to set the classpath of the jetty plugin to include the target/classes and resources directories of each JAR module, instead of the actual JARs in the local repository?

Thanks!
Yaniv

Best Answer

This isn't possible with a multi-module Maven project. A cardinal rule of Maven projects is that each project should be able to stand alone. That doesn't preclude them from being built together, but any one project should be able to be built by itself so long as all it's dependencies are satisfied.

In this case, it means that the WAR project cannot look out to the other projects to see if they need to be updated, the POM for those other projects are the definitive declaration of what needs to be done to build the artifact. And once the artifact is built, it is put in the local repository. There is no association between the source files and the artifact at that point, so there's no way to tell what source files would trigger a rebuild of the artifact that the WAR depends on.

Related Solutions

Java – How to tell Maven to use the latest version of a dependency

NOTE:

The mentioned LATEST and RELEASE metaversions have been dropped for plugin dependencies in Maven 3 "for the sake of reproducible builds", over 6 years ago. (They still work perfectly fine for regular dependencies.) For plugin dependencies please refer to this Maven 3 compliant solution.

If you always want to use the newest version, Maven has two keywords you can use as an alternative to version ranges. You should use these options with care as you are no longer in control of the plugins/dependencies you are using.

When you depend on a plugin or a dependency, you can use the a version value of LATEST or RELEASE. LATEST refers to the latest released or snapshot version of a particular artifact, the most recently deployed artifact in a particular repository. RELEASE refers to the last non-snapshot release in the repository. In general, it is not a best practice to design software which depends on a non-specific version of an artifact. If you are developing software, you might want to use RELEASE or LATEST as a convenience so that you don't have to update version numbers when a new release of a third-party library is released. When you release software, you should always make sure that your project depends on specific versions to reduce the chances of your build or your project being affected by a software release not under your control. Use LATEST and RELEASE with caution, if at all.

See the POM Syntax section of the Maven book for more details. Or see this doc on Dependency Version Ranges, where:

A square bracket ( [ & ] ) means "closed" (inclusive).
A parenthesis ( ( & ) ) means "open" (exclusive).

Here's an example illustrating the various options. In the Maven repository, com.foo:my-foo has the following metadata:

<?xml version="1.0" encoding="UTF-8"?><metadata>
  <groupId>com.foo</groupId>
  <artifactId>my-foo</artifactId>
  <version>2.0.0</version>
  <versioning>
    <release>1.1.1</release>
    <versions>
      <version>1.0</version>
      <version>1.0.1</version>
      <version>1.1</version>
      <version>1.1.1</version>
      <version>2.0.0</version>
    </versions>
    <lastUpdated>20090722140000</lastUpdated>
  </versioning>
</metadata>

If a dependency on that artifact is required, you have the following options (other version ranges can be specified of course, just showing the relevant ones here):

Declare an exact version (will always resolve to 1.0.1):

<version>[1.0.1]</version>

Declare an explicit version (will always resolve to 1.0.1 unless a collision occurs, when Maven will select a matching version):

<version>1.0.1</version>

Declare a version range for all 1.x (will currently resolve to 1.1.1):

<version>[1.0.0,2.0.0)</version>

Declare an open-ended version range (will resolve to 2.0.0):

<version>[1.0.0,)</version>

Declare the version as LATEST (will resolve to 2.0.0) (removed from maven 3.x)

<version>LATEST</version>

Declare the version as RELEASE (will resolve to 1.1.1) (removed from maven 3.x):

<version>RELEASE</version>

Note that by default your own deployments will update the "latest" entry in the Maven metadata, but to update the "release" entry, you need to activate the "release-profile" from the Maven super POM. You can do this with either "-Prelease-profile" or "-DperformRelease=true"

It's worth emphasising that any approach that allows Maven to pick the dependency versions (LATEST, RELEASE, and version ranges) can leave you open to build time issues, as later versions can have different behaviour (for example the dependency plugin has previously switched a default value from true to false, with confusing results).

It is therefore generally a good idea to define exact versions in releases. As Tim's answer points out, the maven-versions-plugin is a handy tool for updating dependency versions, particularly the versions:use-latest-versions and versions:use-latest-releases goals.

Maven – How to run jetty:run-war using a war defined by maven coordinates

The jetty plugin's run-war goal has a element which takes a string path to a war to deploy. I'd much rather specify the war to deploy using the maven coordinates defined by our web module. Is there any way to do this?

This is not really the maven jetty plugin is supposed to be used, the plugin deploys the war of the current module, what you want to do is not supported by default.

Section 4.13 of "Better Builds with Maven" describes using cargo to deploy a war specified using maven coordinates,

Yes, Cargo can do this in a clean way.

but that's serious overkill given that we're using jetty.

I don't agree. First, the jetty plugin doesn't support what you want to do out of the box (so it may not be the right tool). Second, serious overkill is highly exaggerated, a misconception actually, especially given that cargo requires very little configuration (zero?) for an embedded Jetty.

More reasonable IMO is using dependency:copy to copy the just-built-and-installed war artifact to a fixed path in the functional tests module's target directory

No offense but your whole question sounds a bit like: I have a hammer, it was fine for a nail, can I use it for a screw given that getting a screw driver seems a serious overkill? To answer this question (which is somehow what you are saying), you can use dependency:copy and get the whole thing working with the maven jetty plugin, but this is a hack (and since you're actually not asking any question, I guess you wanted an opinion on this). Of course the final decision belongs to you :)

Just in case, here is how I would implement this with Cargo:

<dependencies>
  <dependency>
    <groupId>war group id</groupId>
    <artifactId>war artifact id</artifactId>
    <type>war</type>
    <version>war version</version>
  </dependency>
  ...
</dependencies>
...
<build>
  <plugins>
    <plugin>
      <groupId>org.codehaus.cargo</groupId>
      <artifactId>cargo-maven2-plugin</artifactId>
      <configuration>
        <!-- Container configuration -->
        <container>
          <containerId>jetty6x</containerId>
          <type>embedded</type>
        </container>
        <!-- Configuration to use with the container or the deployer -->
        <configuration>
          <deployables>
            <deployable>
              <groupId>war group id</groupId>
              <artifactId>war artifact id</artifactId>
              <type>war</type>
              <properties>
                <context>war context</context>
              </properties>
            </deployable>
          </deployables>
        </configuration>
        <!-- Don't wait, execute the tests after the container is started -->
        <wait>false</wait>
      </configuration>
      <executions>
        <execution>
          <id>start-container</id>
          <phase>pre-integration-test</phase>
          <goals>
            <goal>start</goal>
          </goals>
        </execution>
        <execution>
          <id>stop-container</id>
          <phase>post-integration-test</phase>
          <goals>
            <goal>stop</goal>
          </goals>
        </execution>
      </executions>
    </plugin>
    ...
  </plugins>
  ...
</build>

And I don't think that this can be objectively qualified as a "serious overkill".

Best Answer

Related Solutions

Java – How to tell Maven to use the latest version of a dependency

Maven – How to run jetty:run-war using a war defined by maven coordinates

Related Topic