Hi Benson! > However, a dependency *has* changed,
Yea, thanks for the example! I think I kind of know what you mean now (I hope). That is why I introduced point A.) in the WiKi description [1]. "If any of those tests indicate a change then we force a 'clean' on the module and on all depending downstream modules." This will kind of make an intelligent mvn clean install, where the 'clean' lifecycle only gets invoked if an external change got detected. And only on the modules which are affected, others will remain untouched. I'm even trying to spare running the tests for those unaffected modules. Just need to figure a way to force running the tests manually. Thats why I thought about -ni and -i ... What makes it a bit more complicated is that there is a slightly different behaviour for all phases < package and >= package in maven. But by combining A.) and B.) we should get this working as well. LieGrue, strub [1] https://cwiki.apache.org/confluence/display/MAVEN/Incremental+Builds ----- Original Message ----- > From: Benson Margulies <bimargul...@gmail.com> > To: Maven Developers List <dev@maven.apache.org>; Mark Struberg > <strub...@yahoo.de> > Cc: > Sent: Monday, August 27, 2012 11:58 PM > Subject: Re: improving incremental builds > > On Mon, Aug 27, 2012 at 5:56 PM, Mark Struberg <strub...@yahoo.de> wrote: >> It's a chain. >> The maven-compiler-plugin sees that there are stale sources or changed > dependencies and compiles the sources. >> The jar plugin sees that there are changed classes which have a newer > timestamp than the jar file, so it creates the jar again. >> The maven-shade-plugin will see the md5 of the jar changed (or detect > otherwise that this is not a shaded jar) and trigger the shading. > > Not good enough. Let me describe the failure mode. > > No sources have changed. So the compiler plugin doesn't recompile. > > So, no .class files have changed, so the jar plugin doesn't jar. > > However, a dependency *has* changed, so the shade plugin needs a clean > input. But it doesn't have a clean input, since the only thing around > is the jar it shaded last time around. > > The only fix I can see is if the shade plugin keeps around a copy of > the original unshaded jar when it shades, and uses that to redo the > shade when all of this happens. > > > >> >> Of course, most of those plugins do not yet support this. But there is > nothing stopping us from hacking that ;) >> >> LieGrue, >> strub >> >> >> >> >> ----- Original Message ----- >>> From: Benson Margulies <bimargul...@gmail.com> >>> To: Maven Developers List <dev@maven.apache.org>; Mark Struberg > <strub...@yahoo.de> >>> Cc: >>> Sent: Monday, August 27, 2012 11:13 PM >>> Subject: Re: improving incremental builds >>> >>> Mark, I don't see how this helps. If the jar plugin hasn't > rebuilt the >>> jar, the shade plugin can't rebuild the jar, even if, for other >>> reasons, it needs to. It has knowledge that the jar plugin lacks. >>> >>> >>> >>> On Mon, Aug 27, 2012 at 4:04 PM, Mark Struberg > <strub...@yahoo.de> wrote: >>>> the shade plugin would just need to store a local status file with > the md5 >>> of the created result. >>>> Or add the info to the manifest as you proposed. >>>> >>>> The main point is that this should be up to the > maven-shade-plugin, as it >>> is the only one who knows when to repeat this step. >>>> >>>> LieGrue, >>>> strub >>>> >>>> >>>> >>>> >>>>> ________________________________ >>>>> From: Stephen Connolly <stephen.alan.conno...@gmail.com> >>>>> To: Maven Developers List <dev@maven.apache.org>; Mark > Struberg >>> <strub...@yahoo.de> >>>>> Sent: Monday, August 27, 2012 9:53 PM >>>>> Subject: Re: improving incremental builds >>>>> >>>>> >>>>> The issue (for benson) is when the shade plugin modifies after > the class >>> files have changed... the jar plugin will currently skip recreating the > jar, and >>> he has no way of knowing if the jar file has been shaded or not.... the > solution >>> is to have the manifest.mf include an entry that indicates created by > shade, so >>> that shade can safely skip >>>>> >>>>> >>>>> On 27 August 2012 19:39, Mark Struberg > <strub...@yahoo.de> wrote: >>>>> >>>>> Not sure if I get the problem. >>>>>> >>>>>> The timestamp of the input files is still < than the > timestamp of >>> the jar file. Regardless if it later got modified by the shade-plugin > or not. >>>>>> >>>>>> LieGrue, >>>>>> strub >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> ________________________________ >>>>>>> From: Stephen Connolly > <stephen.alan.conno...@gmail.com> >>>>>> >>>>>>> To: Maven Developers List <dev@maven.apache.org> >>>>>>> Cc: Mark Struberg <strub...@yahoo.de> >>>>>>> Sent: Monday, August 27, 2012 8:11 PM >>>>>> >>>>>>> Subject: Re: improving incremental builds >>>>>>> >>>>>>> >>>>>>> On 27 August 2012 19:10, Stephen Connolly >>> <stephen.alan.conno...@gmail.com> wrote: >>>>>>> >>>>>>> On 27 August 2012 18:09, Benson Margulies >>> <bimargul...@gmail.com> wrote: >>>>>>>> >>>>>>>> On Mon, Aug 27, 2012 at 12:07 PM, Mark Struberg >>> <strub...@yahoo.de> wrote: >>>>>>>>>> build1 and build 2 are different modules > or >>> different mvn invocations with some time inbetween? >>>>>>>>>> >>>>>>>>>> Of course we will need to test all plugins > to >>> behave incremental like! Means the maven-shade-plugin should check > itself >>> whether it needs shading or not at all. >>>>>>>>> >>>>>>>>> Two builds, separated in time, of exactly the > same >>> module. >>>>>>>>> >>>>>>>>> The problem here is that the jar plugin has > already >>> decided not to >>>>>>>>> rebuild the jar by the time the shade plugin > gets there, >>> and I have no >>>>>>>>> idea how to make the shade plugin play along. >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Any chance we can get the jar plugin to inspect > some of the >>> artifacts that it generates into the jar to see if they are consistent > with what >>> the jar plugin produces... >>>>>>>> >>>>>>>> >>>>>>>> I'm looking at you META-INF/MANIFEST.MF >>>>>>>> >>>>>>>> >>>>>>>> I.O.W. if the >>>>>>>> >>>>>>>> >>>>>>>> Created-By: Apache Maven 3.0.4 (Maven JAR Plugin) >>>>>>>> >>>>>>>> >>>>>>>> is switched to >>>>>>>> >>>>>>>> >>>>>>>> Created-By: Apache Maven 3.0.4 (Maven Shade Plugin) >>>>>>>> >>>>>>>> >>>>>>>> Then the Maven JAR plugin can infer that the > timestamp check >>> is pointless, and force regen >>>>>>>> >>>>>>> >>>>>>> >>>>>>> And people customizing that header can just live with > the issues >>> that creates. >>>>>>> >>>>>>> -Stephen >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> But the worst thing happening would be > that we >>> compile too much. Thats still better than a full mvn clean install :) >>>>>>>>>> >>>>>>>>>> LieGrue, >>>>>>>>>> strub >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ----- Original Message ----- >>>>>>>>>>> From: Benson Margulies >>> <bimargul...@gmail.com> >>>>>>>>>>> To: Maven Developers List >>> <dev@maven.apache.org>; Mark Struberg <strub...@yahoo.de> >>>>>>>>>>> Cc: >>>>>>>>>>> Sent: Monday, August 27, 2012 5:07 PM >>>>>>>>>>> Subject: Re: improving incremental > builds >>>>>>>>>>> >>>>>>>>>>> On Mon, Aug 27, 2012 at 8:40 AM, Mark > Struberg >>> <strub...@yahoo.de> wrote: >>>>>>>>>>>> We might implement this by > storing the >>> list of all activated profiles + all >>>>>>>>>>> resolved environment properties in a > file in >>> target/ somewhere. >>>>>>>>>>>> That would be part of a.) in my > previous >>> mail to Romain. >>>>>>>>>>> >>>>>>>>>>> How about the situation with shade? >>>>>>>>>>> >>>>>>>>>>> Build 1 runs shade and it replaces the > primary >>> build artifact with a shaded one. >>>>>>>>>>> >>>>>>>>>>> Build 2 sees that nothing has changed, > but >>> shade doesn't know, and it >>>>>>>>>>> reshades, eating its own output with a > ton of >>> messages. >>>>>>>>>>> >>>>>>>>>>> Can I fix this in shade with current >>> technologies? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> LieGrue, >>>>>>>>>>>> strub >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> ----- Original Message ----- >>>>>>>>>>>>> From: Anders Hammar >>> <and...@hammar.net> >>>>>>>>>>>>> To: Maven Developers List >>> <dev@maven.apache.org>; Mark Struberg >>>>>>>>>>> <strub...@yahoo.de> >>>>>>>>>>>>> Cc: >>>>>>>>>>>>> Sent: Monday, August 27, 2012 > 12:24 PM >>>>>>>>>>>>> Subject: Re: improving > incremental >>> builds >>>>>>>>>>>>> >>>>>>>>>>>>>> +0 for auto detecting > changed >>> scenarios. If someone changes a >>>>>>>>>>> profile or >>>>>>>>>>>>> the whole pom, then I'd > expect he >>> invokes a clean manually. We >>>>>>>>>>> have to >>>>>>>>>>>>> document this expectation of > course. >>>>>>>>>>>>> >>>>>>>>>>>>> What do others think of this? > I'm >>> thinking it would be awesome (but >>>>>>>>>>>>> maybe difficult) if plugins > could >>> determine if its configuration has >>>>>>>>>>>>> changed, and then handle this >>> automatically. If there are to many >>>>>>>>>>>>> cases where a manual clean > build is >>> required, I believe people will >>>>>>>>>>>>> continue to do "mvn > clean >>> install" (which I see all the time >>>>>>>>>>> with >>>>>>>>>>>>> developers), which I think is > what we >>> try to get away from. >>>>>>>>>>>>> >>>>>>>>>>>>> /Anders >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> LieGrue, >>>>>>>>>>>>>> strub >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> ----- Original Message > ----- >>>>>>>>>>>>>>> From: Anders Hammar >>> <and...@hammar.net> >>>>>>>>>>>>>>> To: Maven Developers > List >>> <dev@maven.apache.org> >>>>>>>>>>>>>>> Cc: >>>>>>>>>>>>>>> Sent: Monday, August > 27, 2012 >>> 9:57 AM >>>>>>>>>>>>>>> Subject: Re: > improving >>> incremental builds >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I already > started >>> tweaking the m-compiler-plugin and >>>>>>>>>>> found quite >>>>>>>>>>>>> scary >>>>>>>>>>>>>>> issues. There is > e.g. >>> MCOMPILER-21 (open since 2005) which >>>>>>>>>>> prevents >>>>>>>>>>>>> incremental >>>>>>>>>>>>>>> build and would kick > in in >>> your scenario. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This is interesting. > I've >>> looked a bit at Mojo's JAXB >>>>>>>>>>> plugin in >>>>>>>>>>>>> the >>>>>>>>>>>>>>> context of detecting > stale >>> generated files (i.e. need to >>>>>>>>>>> re-generate) >>>>>>>>>>>>>>> and it's similar > to this. >>> It would extremely nice if there >>>>>>>>>>> would be >>>>>>>>>>>>> a >>>>>>>>>>>>>>> common > "framework" >>> for handling incremental builds. >>>>>>>>>>>>>>> In addition to > what's >>> been mentioned in the jira (I just >>>>>>>>>>> browsed it >>>>>>>>>>>>>>> quickly), we have > cases when >>> includes/excludes change, the >>>>>>>>>>> sourceDir >>>>>>>>>>>>>>> changes, etc which > should >>> trigger cleanup and re-compilation. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> /Anders >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I talked about > 2 >>> scenarios >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> a.) all phases >> = >>> package, e.g. mvn verify, mvn >>>>>>>>>>> install, ... >>>>>>>>>>>>> Here we >>>>>>>>>>>>>>> have an artifact on > the disc >>> and could test for the md5 of >>>>>>>>>>> them, right? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> b.) all phases > < >>> package. This is e.g. mvn compile or >>>>>>>>>>> mvn test. >>>>>>>>>>>>> In that >>>>>>>>>>>>>>> case we don't > produce a >>> jar/war/ear/... artifact but only >>>>>>>>>>> get the >>>>>>>>>>>>> files on >>>>>>>>>>>>>>> the disk linked in >>> MavenProject#getProjectArtifacts()... >>>>>>>>>>> file(). This >>>>>>>>>>>>> is the >>>>>>>>>>>>>>> case where the >>> maven-compiler-plugin kicks in. I'm >>>>>>>>>>> currently in the >>>>>>>>>>>>> process >>>>>>>>>>>>>>> of rewriting big > parts of it, >>> mainly I introduced >>>>>>>>>>>>>>>> b.1 a check > for >>> project.artifacts/project.testArtifacts >>>>>>>>>>> .file() >>>>>>>>>>>>> is a >>>>>>>>>>>>>>> local file path >>> .isDirectory() and has files which are newer >>>>>>>>>>> (actually >>>>>>>>>>>>>> =) >>>>>>>>>>>>>>> than the > buildStarted >>> timestamp. >>>>>>>>>>>>>>>> b.2 check > whether >>> there are any *.java (sourceincludes) >>>>>>>>>>> files >>>>>>>>>>>>> which are >>>>>>>>>>>>>>> newer than their > class files. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> In both cases I > now >>> force a FULL recompile of the module! >>>>>>>>>>>>> Compiling only >>>>>>>>>>>>>>> parts produced > classes which >>> are actually broken! >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> My approach is > the >>> following: compiling a bit too much is >>>>>>>>>>> better >>>>>>>>>>>>> than >>>>>>>>>>>>>>> missing some files > which need >>> compilation. Because the later >>>>>>>>>>> is exactly >>>>>>>>>>>>> the >>>>>>>>>>>>>>> reason why noone > uses mvn >>> compile but always do a mvn clean >>>>>>>>>>> compile >>>>>>>>>>>>> nowadays. If >>>>>>>>>>>>>>> mvn compile is > reliable, then >>> we will end up being much faster >>>>>>>>>>> than an >>>>>>>>>>>>>>> unconditional full > compile on >>> the whole project! >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> LieGrue, >>>>>>>>>>>>>>>> strub >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> PS: We need to > move all >>> our plugins which still use the >>>>>>>>>>>>>>> > plugin-testing-harness to the >>> maven-invoker-plugin as the >>>>>>>>>>> test-harness >>>>>>>>>>>>> is broken >>>>>>>>>>>>>>> with sisu. (sisu > changed the >>> 'container' field from >>>>>>>>>>> plexus >>>>>>>>>>>>> original: >>>>>>>>>>>>>>> protected to >>> 'private') >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> PPS: how do we > maintain >>> the plexus-compiler-utils stuff? >>>>>>>>>>> This >>>>>>>>>>>>> contains some >>>>>>>>>>>>>>> weirdo bugs which > should get >>> fixed... >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ----- Original > Message >>> ----- >>>>>>>>>>>>>>>>> From: > Olivier Lamy >>> <ol...@apache.org> >>>>>>>>>>>>>>>>> To: Maven > Developers >>> List >>>>>>>>>>> <dev@maven.apache.org>; Mark >>>>>>>>>>>>> Struberg >>>>>>>>>>>>>>> > <strub...@yahoo.de> >>>>>>>>>>>>>>>>> Cc: >>>>>>>>>>>>>>>>> Sent: > Monday, August >>> 27, 2012 9:13 AM >>>>>>>>>>>>>>>>> Subject: > Re: >>> improving incremental builds >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>> Sounds good > idea >>> trying to improve that. >>>>>>>>>>>>>>>>> My > question: on what >>> is based the md5 calculation ? >>>>>>>>>>>>>>>>> If people > don't >>> use 'install' but only >>>>>>>>>>>>> 'test' >>>>>>>>>>>>>>> (perso I use >>>>>>>>>>>>>>>>> that to >>>>>>>>>>>>>>>>> avoid too > much io >>> with jar creation etc..), so in >>>>>>>>>>> such case we >>>>>>>>>>>>> cannot >>>>>>>>>>>>>>>>> do md5 > calculation >>> on the produced artifact. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 2012/8/26 > Mark >>> Struberg <strub...@yahoo.de>: >>>>>>>>>>>>>>>>>> Hi > David! >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> So > your >>> idea is to find the list of changed >>>>>>>>>>> modules >>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>> > then build >>> that list with -amd? >>>>>>>>>>>>>>>>>> Yes, > kind of. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> At the > moment >>> mvn -amd builds the dependents of >>>>>>>>>>> the >>>>>>>>>>>>> _current_ >>>>>>>>>>>>>>> module. If >>>>>>>>>>>>>>>>> you use my > example >>> and change BeanA.java, then run >>>>>>>>>>> mvn -amd >>>>>>>>>>>>> from the >>>>>>>>>>>>>>> root module >>>>>>>>>>>>>>>>> you will > see that >>> only moduleA gets rebuild and >>>>>>>>>>> moduleB >>>>>>>>>>>>> remains >>>>>>>>>>>>>>> original. >>>>>>>>>>>>>>>>> Because > moduleB is >>> not a dependent of the root >>>>>>>>>>> module. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> But > yes, >>> I'm completely with you that we >>>>>>>>>>> have most of >>>>>>>>>>>>> the >>>>>>>>>>>>>>> ingredients >>>>>>>>>>>>>>>>> in the > maven >>> codebase already. At least for the start >>>>>>>>>>> we could >>>>>>>>>>>>> easily >>>>>>>>>>>>>>> detect >>>>>>>>>>>>>>>>> changed > build >>> results and add those to the >>>>>>>>>>> 'amd' list. >>>>>>>>>>>>> That >>>>>>>>>>>>>>> would >>>>>>>>>>>>>>>>> already be > much >>> better than what we have today imo. >>>>>>>>>>> And this >>>>>>>>>>>>> should be >>>>>>>>>>>>>>> pretty >>>>>>>>>>>>>>>>> easy to > implement. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> > Indeed, what I >>> proposed goes a bit beyond -amd. >>>>>>>>>>> I would >>>>>>>>>>>>> not only >>>>>>>>>>>>>>> check the >>>>>>>>>>>>>>>>> current > build tree >>> like -amd does (even if that would >>>>>>>>>>> be a >>>>>>>>>>>>> good start) >>>>>>>>>>>>>>> but >>>>>>>>>>>>>>>>> remember > the md5 of >>> all the dependencies of each >>>>>>>>>>> module >>>>>>>>>>>>> (simply store >>>>>>>>>>>>>>> them in a >>>>>>>>>>>>>>>>> file in > ./target/) >>> And if you find a dependency which >>>>>>>>>>> is not >>>>>>>>>>>>> in the >>>>>>>>>>>>>>> list (e.g. >>>>>>>>>>>>>>>>> after > upgrade from >>> one version to another) or has a >>>>>>>>>>> different >>>>>>>>>>>>> md5 (this >>>>>>>>>>>>>>> covers >>>>>>>>>>>>>>>>> SNAPSHOT > versions) , >>> then we could force a full >>>>>>>>>>> rebuild (mvn >>>>>>>>>>>>> -amd) of >>>>>>>>>>>>>>> this >>>>>>>>>>>>>>>>> module. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> > LieGrue, >>>>>>>>>>>>>>>>>> strub >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> ----- > Original >>> Message ----- >>>>>>>>>>>>>>>>>>> > From: David >>> Jencks >>>>>>>>>>> <david_jen...@yahoo.com> >>>>>>>>>>>>>>>>>>> > To: Maven >>> Developers List >>>>>>>>>>>>> <dev@maven.apache.org> >>>>>>>>>>>>>>>>>>> > Cc: >>>>>>>>>>>>>>>>>>> > Sent: >>> Sunday, August 26, 2012 8:34 AM >>>>>>>>>>>>>>>>>>> > Subject: >>> Re: improving incremental builds >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Is > what you >>> want different from what >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> > mvn -amd >>> moduleA >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> > does? So >>> your idea is to find the list of >>>>>>>>>>> changed >>>>>>>>>>>>> modules and >>>>>>>>>>>>>>> then >>>>>>>>>>>>>>>>> build that >>>>>>>>>>>>>>>>>>> > list with >>> -amd? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> > thanks >>>>>>>>>>>>>>>>>>> > david >>> jencks >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On > Aug 25, >>> 2012, at 1:32 PM, Mark Struberg >>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> > Hi >>> folks! >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> > After >>> a short discussion with Kristian, >>>>>>>>>>> I've >>>>>>>>>>>>> created >>>>>>>>>>>>>>> a small >>>>>>>>>>>>>>>>> app with 2 >>>>>>>>>>>>>>>>>>> > modules >>> which shows a few problems with >>>>>>>>>>> mavens >>>>>>>>>>>>> incremental >>>>>>>>>>>>>>> build logic. >>>>>>>>>>>>>>>>>>>> > And >>> since incremental builds do not >>>>>>>>>>> work well, >>>>>>>>>>>>> people use >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> > $> >>> mvn _clean_ install >>>>>>>>>>>>>>>>>>>> > all >>> the time. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> > We >>> could speed up the development >>>>>>>>>>> effort heavily >>>>>>>>>>>>> if we >>>>>>>>>>>>>>> make >>>>>>>>>>>>>>>>>>>> > $> >>> mvn install >>>>>>>>>>>>>>>>>>>> >>> (without an upfront clean) more >>>>>>>>>>> reliable. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> > The >>> sample [1] consists of moduleA and >>>>>>>>>>> moduleB >>>>>>>>>>>>> with BeanA >>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>> BeanB >>>>>>>>>>>>>>>>>>> >>> respectively. >>>>>>>>>>>>>>>>>>>> > BeanB >>> has a private BeanA field and >>>>>>>>>>> moduleB has >>>>>>>>>>>>> a >>>>>>>>>>>>>>> dependency on >>>>>>>>>>>>>>>>> moduleA. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> > If I >>> change BeanA and just invoke mvn >>>>>>>>>>> install >>>>>>>>>>>>> then only >>>>>>>>>>>>>>> moduleA >>>>>>>>>>>>>>>>> gets >>>>>>>>>>>>>>>>>>> > rebuilt. We >>> currently do not rebuild >>>>>>>>>>> moduleB, but we >>>>>>>>>>>>> should do >>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>> create a >>>>>>>>>>>>>>>>>>> > reliable >>> output. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> > In >>> fact, the incremental build within a >>>>>>>>>>> single >>>>>>>>>>>>> module >>>>>>>>>>>>>>> already >>>>>>>>>>>>>>>>> works to > some >>>>>>>>>>>>>>>>>>> > degrees, >>> but we must detect a change in >>>>>>>>>>> dependencies >>>>>>>>>>>>> and >>>>>>>>>>>>>>> trigger a full >>>>>>>>>>>>>>>>> rebuild >>>>>>>>>>>>>>>>>>> on > all >>> depending modules. This could be done >>>>>>>>>>> by >>>>>>>>>>>>> storing the >>>>>>>>>>>>>>> md5 of all >>>>>>>>>>>>>>>>>>> > dependency >>> artifacts and compare them on the >>>>>>>>>>> next >>>>>>>>>>>>> build. If >>>>>>>>>>>>>>> the md5 of >>>>>>>>>>>>>>>>> a >>>>>>>>>>>>>>>>>>> > dependency >>> did change, then we need to build >>>>>>>>>>> the >>>>>>>>>>>>> module full >>>>>>>>>>>>>>> cycle. >>>>>>>>>>>>>>>>>>>> > Other >>> ideas are welcome. Slaps as well >>>>>>>>>>> if I >>>>>>>>>>>>> forgot some >>>>>>>>>>>>>>> obvious >>>>>>>>>>>>>>>>> stuff and >>>>>>>>>>>>>>>>>>> > all works >>> well already. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>> LieGrue, >>>>>>>>>>>>>>>>>>>> > strub >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> --------------------------------------------------------------------- >>>>>>>>>>>>>>>>>>>> > To >>> unsubscribe, e-mail: >>>>>>>>>>>>> > dev-unsubscr...@maven.apache.org >>>>>>>>>>>>>>>>>>>> > For >>> additional commands, e-mail: >>>>>>>>>>>>>>> > dev-h...@maven.apache.org >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>> >>> --------------------------------------------------------------------- >>>>>>>>>>>>>>>>>>> To >>> unsubscribe, e-mail: >>>>>>>>>>>>> > dev-unsubscr...@maven.apache.org >>>>>>>>>>>>>>>>>>> > For >>> additional commands, e-mail: >>>>>>>>>>>>> dev-h...@maven.apache.org >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>> >>> --------------------------------------------------------------------- >>>>>>>>>>>>>>>>>> To > unsubscribe, >>> e-mail: >>>>>>>>>>> dev-unsubscr...@maven.apache.org >>>>>>>>>>>>>>>>>> For > additional >>> commands, e-mail: >>>>>>>>>>>>> dev-h...@maven.apache.org >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> Olivier > Lamy >>>>>>>>>>>>>>>>> Talend: >>> http://coders.talend.com >>>>>>>>>>>>>>>>> >>> http://twitter.com/olamy | >>>>>>>>>>> http://linkedin.com/in/olamy >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> --------------------------------------------------------------------- >>>>>>>>>>>>>>>> To unsubscribe, > e-mail: >>> dev-unsubscr...@maven.apache.org >>>>>>>>>>>>>>>> For additional > commands, >>> e-mail: >>>>>>>>>>> dev-h...@maven.apache.org >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>> >>> --------------------------------------------------------------------- >>>>>>>>>>>>>>> To unsubscribe, > e-mail: >>> dev-unsubscr...@maven.apache.org >>>>>>>>>>>>>>> For additional > commands, >>> e-mail: dev-h...@maven.apache.org >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>> >>> --------------------------------------------------------------------- >>>>>>>>>>>>>> To unsubscribe, e-mail: >>> dev-unsubscr...@maven.apache.org >>>>>>>>>>>>>> For additional commands, > e-mail: >>> dev-h...@maven.apache.org >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>> --------------------------------------------------------------------- >>>>>>>>>>>>> To unsubscribe, e-mail: >>> dev-unsubscr...@maven.apache.org >>>>>>>>>>>>> For additional commands, > e-mail: >>> dev-h...@maven.apache.org >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>> --------------------------------------------------------------------- >>>>>>>>>>>> To unsubscribe, e-mail: >>> dev-unsubscr...@maven.apache.org >>>>>>>>>>>> For additional commands, e-mail: >>> dev-h...@maven.apache.org >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>> --------------------------------------------------------------------- >>>>>>>>>>> To unsubscribe, e-mail: >>> dev-unsubscr...@maven.apache.org >>>>>>>>>>> For additional commands, e-mail: >>> dev-h...@maven.apache.org >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>> --------------------------------------------------------------------- >>>>>>>>>> To unsubscribe, e-mail: >>> dev-unsubscr...@maven.apache.org >>>>>>>>>> For additional commands, e-mail: >>> dev-h...@maven.apache.org >>>>>>>>>> >>>>>>>>> >>>>>>>>> > --------------------------------------------------------------------- >>>>>>>>> To unsubscribe, e-mail: > dev-unsubscr...@maven.apache.org >>>>>>>>> For additional commands, e-mail: >>> dev-h...@maven.apache.org >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> > --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> > --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
