6

I tend to avoid using mvn install in my multi-module projects because I feel like I then don't know which exact version of a submodule is then used when building / launching other submodules (particularly when switching between branches very often).
I tend to use mvn package a lot and then mvn verify.

I'm now facing the issue in a FOSS project (a Maven archetype moreover) where I'd like to use Maven's best practices.
It's a multi-module project with a webapp submodule depending on the other modules, and what worries me is the ease of development along with mvn jetty:run (or jetty:start).

Currently, I defined 2 profiles:

  1. prod, the default one, declares dependencies on the other submodules;
  2. dev on the other hand does not depend on the other modules, and configures the jetty-maven-plugin by adding the other modules' output directories as extraClasspath and resourcesAsCSV.
    That way, I can mvn package once and then cd webapp && mvn jetty:start -Pdev and quickly iterate, reloading the webapp without the need to even stop the server.

AFAICT, extraClasspath was added for that exact purpose (JETTY-1206).
I've been pointed at the tomcat7-maven-plugin which can resolve modules from the reactor build when using Maven 3 (and I raised an issue to bring the same to Jetty: JETTY-1517), but that hardly solve my

If I hadn't removed the dependency on the other submodules from in dev profile, I'd have had to do an mvn install first so that validating the POM doesn't fail, even if jetty:start doesn't use those dependencies afterwards.

So here's my question: is mvn install really that common? or my approach of putting the intra-reactor dependencies only in the prod profile OK?

(note that I have the exact same problem with the gwt-maven-plugin, so please don't tell me to simply switch to Tomcat; that wouldn't even work actually, details here)

Thomas Broyer
  • 64,353
  • 7
  • 91
  • 164
  • What i don't understand is why you have dependencies in the former profile whereas you don't in the second one? Are there dependencies between the modules or not? If so you have to define them otherwise you build could not work correctly. Or do i oversight something? – khmarbaise May 21 '12 at 14:41
  • Building in the `dev` profile indeed fails here, it's only used for _running_ the submodule, where it loads its dependencies by _file path_ rather than _Maven dependencies_. It doesn't feel clean to me either, but installing half-baked artifacts (skipping a few time-consuming tasks that I don't need at dev time) is no better in my mind. – Thomas Broyer May 21 '12 at 15:05

3 Answers3

1

The mvn install is common in particular in relationship with multi-module builds, cause it will give you the chance to run a single module from your multi-module build.

This can be achieved by using:

mvn -pl submodule LifeCycle
khmarbaise
  • 92,914
  • 28
  • 189
  • 235
  • When it comes to SNAPSHOTs, then you happen to run your module against whatever was installed last; might be a stable version from last week (unlikely if you `install` regularly, but still possible if you use `-am` a lot and didn't touch `submodule` for a while), or one from another local branch, containing a breaking change (quite likely as soon as you use a DVCS). This is why I'd rather use `-am` here, but it doesn't work for all values of `LifeCycle` (`jetty:run` is one such example). I'm looking for the _best practice_ here, not only a pragmatic answer. – Thomas Broyer May 21 '12 at 14:58
  • But usually you do a mvn install before and multiple time a mvn -pl ...if you know you changes something you can redo the mvn install or use the -am option. – khmarbaise May 21 '12 at 15:11
  • BTW: jetty:run is not a lifecycle it's a goal. – khmarbaise May 21 '12 at 15:13
1

I just found a workaround (which seems logical as an afterthought): https://jira.codehaus.org/browse/JETTY-1517?focusedCommentId=306630&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-306630

In brief: skip the plugin by default in the parent module then re-enable it where needed.

This however only works if the plugin can be skipped (i.e. has a skip configuration) and is only used in one specific submodule, and it has to be selectively done for each plugin you need/want to run that way (in my case, jetty:run and gwt:run).

Thomas Broyer
  • 64,353
  • 7
  • 91
  • 164
0

I do most of my development on my laptop. For the projects I'm currently working on, my local repository is really more of a temporary holding area. I run mvn install all the time. Putting artifacts in one's local repo is the only way I know of to share built artifacts between projects, especially if you are working on projects which are related but are not (and should not be) part of the same multi-module build.

When I'm done developing I commit changes to the shared SCM and let Jenkins build & deploy the code to the shared remote repo. Then I either blow away the changed projects in my local repository so the next build brings down the freshly built artifacts, or I run Maven with -U to force updates.

This works well for me, YMMV.

user944849
  • 14,524
  • 2
  • 61
  • 83
  • Thanks, but that doesn't answer the question: what is the _best practice_? – Thomas Broyer May 22 '12 at 08:31
  • I have spent months digging in Maven documentation and forums and have not seen discussion about best practices for installing to the local repo. Perhaps it's worth a post to the [Maven User's Group](http://maven.40175.n5.nabble.com/Maven-Users-f40176.html). Many of the Maven committers hang out there. – user944849 May 22 '12 at 13:18
  • Yup, exactly what I did 2 hours ago (and probably pending moderation now) – Thomas Broyer May 22 '12 at 14:24