On Mon, Dec 17, 2012 at 12:36 PM, Stephen Connolly <stephen.alan.conno...@gmail.com> wrote: > Current work on Maven compiler plugin version 3.0 is adding support for an > incremental mode. > > It is a tricky balance to cut, as if incremental mode is too aggressive, > you compile more than is strictly necessary... and if too lax, you compile > less than is required and people end up having to run "clean" first again. > > Another issue is that people abuse the "install" hack far more often than > they should... > > In fact it seems most people's default mode with Maven is to go "mvn clean > install". > > There are a lot of issues with that, not least being that you are abusing > the local repository cache.
I'm so glad you mention this, I though I was alone in thinking that way! See for example the responses to http://stackoverflow.com/q/10686682/116472 and the total lack of reply to http://users.markmail.org/thread/3tpgtmsisxbdccw2 This should be more prominently explained in the docs though. And I believe one reason people do that, is that Maven is not really good at making "not install" a sensible default: "-rf" in a reactor build will resolves skipped modules from the repository! > Where this really kicks in is when people have made their build to *rely* > on artifacts being installed in the cache... cue ensuing hilarity when > using the release plugin... "solved" (if even detected) by people changing > to <preparationGoals>clean install</preparationGoals>... of course the real > solution is to fix your build so that it works with "clean verify" on a > 'virgin' set of version numbers. > > One of your points about partial phases actually misses one of the key > things about Maven that a lot of people have missed... namely that you > don't have to go all the way. > > The extension of my "install" hack complaint is the "package" hack > complaint. > > If your build requires you to go as far as the "package" phase, then likely > you are missing out on doing it right... might not be your fault, may the > the fault of some plugins you are using... but none the less there are > things you are missing out on. > > My hope is that, for example, some of the tricks I am applying with the > jszip.org's maven plugin will enlighten people into the benefits of getting > your build 'right'... for example > > $ mvn compile jszip:run > > In a multi-module build... now your java classpath is not for the > **/target/*.jar files but for the **/target/classes directories... so you > can have your IDE compile the changed classes, and the classpath scanning > of jszip:run will pick up the changes and reload the servlet container... > With the background compile feature in for example IDEA 12 (I ack that > eclipse's webby plugin does similar to jszip:run... some of my tricks were > picked up from Benjamin) you basically can just write your java and > javascript code and switch back to the browser, hit reload and see the > changes... Nit: you might want to use "mvn process-classes jszip:run" instead of "compile" ;-) > If you do "mvn package jszip:run" however the `target/classes` directory > will have been replaced as the primary artifact by the > `target/${finalName}.jar` and therefore we are limited to watching for the > .jar file to be modified... no more live development. Yes I could hack and > infer the target/classes directory... but that hack would not be the Maven > way. It unfortunately basically only works for the "main artifact" of a packaging=jar module. AFAICT, it won't work if you need the java-source or test-jar (fixed for test-jars in the upcoming Maven 3.1: http://jira.codehaus.org/browse/MNG-5214, but for java-source you have to code your plugins to use getReferenceProjects() and getCompileSourceRoots() –getTestCompileSourceRoots if the dependency has classifier=test-sources– when Artifact#getFile() is null) I'm ready to admit depending on java-source artifacts is kind of an edge-case though (even though it's more than current practice with GWT). > So the phase you invoke depends on your needs. > > You are doing Maven wrong (IMHO) if your entire build cannot work under the > following incremental behaviours: > > 1. Change all the modules to a 'virgin' version number (one that has never > been touched before... don't want the local repo or any remote repos > "helping" us out > 2. "mvn clean" if you cannot clean a clean fresh checkout on virgin version > numbers #fail > 3. "mvn clean generate-sources" if you cannot create all the generated > source code, your IDE experience will be less than stellar #fail This can fail in reactor builds, when generating sources for a module requires compiled classes from a dependency module. One answer to that is that the choice between "process-classes" and "package" in the multi-module scenario above shouldn't be left at the developer's appreciation. More often than not, what I want to do is not "run this goal (or up to this phase) on all modules" but rather "run this goal (or up to this phase) on this submodule (and possibly the modules that depends on it), and simply package (or compile/process-classes) on the modules it depends on". Currently, I'd have to "mvn install" a few modules to be able to run "mvn some-goal -rf moduleX". What I generally want is "build everything needed to do X", and I do not really care whether "build" means "package" or "process-classes" (and as Arnaud said, it's also dependent on the packaging types). But note that Peter Miller's view is to rather always build "everything" ("mvn package" or "mvn verify"): compile and run tests everywhere and let the build tool decide what it really *needs* to do. Maven's current situation is a mix of "build too few" (compilation, leading to "mvn clean"), "build too much" (running tests; leading to "mvn install" and "mvn -rf X"), and other side-effects of not tracking changes (compilation, resource-copying and packaging; leading again to "mvn clean"); nothing that cannot be fixed though. -- Thomas Broyer /tɔ.ma.bʁwa.je/ --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
