I really like to pick up the work again, but currently busy with graduating
another project.
The next important points to do are
* inter-project change detection. If you have a dependency to another project
which changed, you need to basically do a full build on your depending module.
Thus said, if we have this we do _not_ need to rebuild any other modules which
do not have such a dependency.
* making maven-resource-plugin incremential ready. Later on other plugins, but
m-r-p is really used a lots and if you have a new config, then you most likely
also like to rebuild/retest your project
* surefire integration. If no dependency got changed and no code/previous stuff
got changed, you most probably also do not like to run all the tests again.
This could _seriously_ cut down build times!
LieGrue,
strub
----- Original Message -----
> From: Stephen Connolly <stephen.alan.conno...@gmail.com>
> To: Maven Users List <users@maven.apache.org>
> Cc:
> Sent: Monday, December 17, 2012 12:36 PM
> Subject: Re: Seeking feedback on “Recursive Maven considered harmful”
>
> 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
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
