This is the intended behavior.
For instance, if you change a method signature of a class, only this class
would be recompiled in the old situation, causing a false positive:
classes depending on this method should be recompiled as well. For that
reason most users run "mvn clean install", where they should only need to
run "mvn verify", especially in huge multimodule projects.
Compilers are quite fast, so the bit of loss for recompiling everything is
worth the stability.
But the m-compiler-p seems to be a bit too aggressive sometimes, although
more reliable AFAIK.
Robert
Op Sun, 20 Jan 2013 11:15:12 +0100 schreef Tony Chemit
<[email protected]>:
On Sun, 20 Jan 2013 11:11:31 +0100
Tony Chemit <[email protected]> wrote:
On Sat, 19 Jan 2013 16:46:09 +0100
Olivier Lamy <[email protected]> wrote:
> 2013/1/19 Tony Chemit <[email protected]>:
> > On Thu, 17 Jan 2013 21:17:35 +0100
> > Olivier Lamy <[email protected]> wrote:
> >
> > +0.
> >
> > m-compiler-p to 3.0 is it a real good idea ?
> >
> > I tried it, and it did not pleased me to recompile all a module
each time there is a single modification inside it.
> >
>
> You mean if module B depends on A, change in A -> module B recompiled
> ?
No when a java file was modified in a module, then the whole module is
recompiled. The message is: Changes detected - recompiling the module!
I just check doing a touch on a single java file, and the whole module
was recompiled :(. But may-be this is the desired behaviour (perso I
don't understand why and I don't like this, just really want to avoid
recompiling all my classes each time I touch a single one).
If it is a defect, told me I will fill something about it.
tony
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
