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.
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...
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.
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
4. "mvn clean compile" if you cannot compile all your production code
without bundling up jars and stuffing them in the local repo cache, shame
on you #fail
5. "mvn clean test-compile" if you cannot compile all your test code #fail
6. "mvn clean package -DskipTests" if those packaged artifacts need to go
into the local repo cache for subsequent modules to find them, you have a
subtly broken build #fail
7. "mvn clean verify -DskipTests" if you cannot use the release plugin's
default test of a releaseable artifact on virgin version numbers: #fail
Note that all these tests are designed to be quick (i.e. not looking at
whether you have working test cases and ignoring the results of tests) and
to be run in succession on the same virgin version number(s)
Not that you will use all of the above commands on a regular basis... but
if you cannot pass all 6 tests, you are not enabling the full power of
Maven and I personally will not listen to you complaining about how "Maven
sucks" because the truth is *your* build sucks and therefore we cannot make
any inference as to the sucky-ness of Maven (which may indeed suck... but I
have yet to see a build that passes my tests and shows Maven to suck)
-Stephen
On 17 December 2012 10:50, Thomas Broyer <t.bro...@gmail.com> wrote:
> Hi,
>
> On his blog, Lex Spoon makes some interesting points against most
> build systems, using Maven as an example:
> http://blog.lexspoon.org/2012/12/recursive-maven-considered-harmful.html
> In related news, I've heard people complain about “insanely long build
> times via building unnecessary things” and tracking down the cause to
> being Maven, to the extent that they're thinking about making their
> own build system (many are Xooglers and they probably would like.
>
> I've made some proposals for improvements in the comments of Lex's
> post, and I'm eager to know what other people think, particularly
> Maven core developers/contributors. Has this been ever discussed? If
> yes, is this planned or has it been dismissed? In the latter case, for
> which reasons?
>
> Thanks in advance,
>
> --
> Thomas Broyer
> /tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
