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 <[email protected]> > To: Maven Developers List <[email protected]> > 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: [email protected] >> For additional commands, e-mail: [email protected] >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
