24

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

yby
  • 896
  • 8
  • 24

5 Answers5

7

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.

Brian Topping
  • 3,049
  • 25
  • 32
  • 5
    This is pretty horrible. As someone who's coming from other build systems I really hate this restriction and hope it's not true. Maven knows which modules reside on the file system because they're specified in the parent's pom.xml. As a result it should be able to always rebuild those projects. It doesn't need to do anything super intelligent, but an option to always rebuild would be nice. – Ben McCann Dec 07 '10 at 03:47
  • 3
    Nobody builds with Maven for rapid iterations. Load your project into an IDE ... IntelliJ IDEA, Eclipse or Netbeans all understand how to parse Maven projects, and if you don't have special plugins (or the plugins only need to be run after specific files change), you'll never experience these as issues that you particularly care about. – Brian Topping Dec 07 '10 at 03:54
  • So how do you do rapid iterations in a web app then? Is there something you do in the IDE instead of "mvn jetty:run"? Or I guess the answer is basically that you just can't do rapid iterations for a web app and have to suffer through reinstalling your project all the time? – Ben McCann Dec 07 '10 at 04:13
  • 4
    I very much import the project into my IDE. I use IntelliJ IDEA, which can build and deploy with a single click to a half-dozen different containers, including Tomcat, Jetty, Glassfish, and Spring DM (in IDEA x). The jetty:run goal is great for projects that are checked in and just need to be easily run by downloaders, but is not a good choice at all for iterative development. – Brian Topping Dec 07 '10 at 04:16
  • Ah, interesting. So it sounds like I'll have to install Jetty locally and find an Eclipse plugin that can deploy to it. Thanks for the info Brian! – Ben McCann Dec 07 '10 at 04:23
  • 1
    You should be able to find an eclipse plugin that can run Jetty from within Eclipse, automatically connecting to the debugger as a part of the iterative cycle. – Brian Topping Dec 07 '10 at 04:26
  • By the way, please uprate comments and answers that are helpful, I'm kind of new around these parts! :-D Cheers – Brian Topping Dec 07 '10 at 04:27
  • @Ben thanks for echoing my exact thoughts.. @Brian thanks for the great comments. I was also under the impression that jetty:run should be used for rapid iterations. Thanks for clearing this matter out for me :) – yby Dec 07 '10 at 07:54
3

In Eclipse, you can use "Run Jetty" plugin to achieve this.
In IDEA's Run Configuration, there is an option 'Resolve Workspace artifacts', check it.

Kaibin
  • 464
  • 2
  • 8
  • 18
2

If you use M2Eclipse (Eclipse plug-in for a close integration of Maven within Eclipse), you can run your jetty:run goal in the web module and other dependencies will be taken into account from your workspace, even if they are not at all available in your local repository.

There is just an option in your run to tell Maven to resolve your modules in the workspace itself (by default, it would just fetch what is deployed in the local repository).

Unfortunately, I cannot have the same behaviour in IDEA and I have to run an install before running the jetty:run on the web module.

  • 2
    Is this true? I can't get it to work. See: http://stackoverflow.com/questions/5571442/how-to-get-maven-plugin-to-use-eclipse-workspace-resolution – ccleve Apr 07 '11 at 02:26
1

Based on this answer:Best practice wrt. `mvn install`, multi-module projects, and running one submodule a workaround around Mavens horrible restrictions and reactor limitations is to define the plugin in the parent pom with skip true, and then reenable it in the respective submodule using skip false.

Community
  • 1
  • 1
tkruse
  • 8,363
  • 5
  • 43
  • 70
1

I solved by using a maven launcher and configuring Resolve Workspace artifacts, that is not checked by default enter image description here

Gardella Juan
  • 342
  • 4
  • 11