how do you know the resource handling is not depending on other jars?
I know this is not perfect, but if you have a bigger project then you have a tree of depending modules. And not every module is depending on any other. So while a forced 'clean' on _those_ depending modules is more expensive then just doing nothing it is still the only practical way. Otherwise the plugins would need to know exactly what happened in the other modules. Please also note that we do treat external dependencies pretty similar to reactor modules once we reach a certain phase in the build lifecycle. I know that doing this 'clean' is not free of cost, but this is still _way_ cheaper than doing a mvn clean install in any case as it is needed right now! LieGrue, strub ----- Original Message ----- > From: Thomas Broyer <t.bro...@gmail.com> > To: Maven Users List <users@maven.apache.org>; Mark Struberg > <strub...@yahoo.de> > Cc: > Sent: Monday, December 17, 2012 3:16 PM > Subject: Re: Seeking feedback on “Recursive Maven considered harmful” > > On Mon, Dec 17, 2012 at 12:47 PM, Mark Struberg <strub...@yahoo.de> wrote: >> 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! > > DISCLAIMER: I'm over-simplifying things here by only considering Java > projects, I know it's more complex than that. > > Some of the things above above and in > https://cwiki.apache.org/MAVEN/incremental-builds.html are kind of > scary! > Because one of your dependencies has changed does not mean you have to > do a "clean": let each plugin decide. For instance, the resources > plugin doesn't really care what your dependencies are. The compiler > plugin will use some of them though, and it can simply include them in > its staleness check. > > Ideally the compiler plugin would track dependencies at the class (or > file) level. In the example from the wiki, it would store in > target/maven.status/compiler.status that BeanA2 depends on BeanA and > thus needs to be recompiled if BeanA has changed. In ModuleB, it could > be enough to track that BeanA comes from ModuleA and that BeanB thus > needs to be recompiled if the ModuleA dependency has changed. Because > we're in a multi-module build though, we might want to track the > direct dependency to BeanA as ModuleB could be compiled with the > target/classes of ModuleA, so you could skip recompiling BeanB if only > BeanA2 has changed. AIUI, IDEs are already doing such dependency > tracking, and it does not seem to be taking that much time to compute > the dependency graph and then incrementally update it as files change. > The compiler plugin also needs to remove BeanA2.class from > target/classes when I delete BeanA2.java from src/main/java or I > rename it (and similarly for the resources plugin). > > Similarly, you'd want to track class/files dependencies to only run > those tests related to the classes that changed. A less ambitious goal > would, as you propose, only skip running tests altogether when > nothing's changed, and run all of them otherwise (as today), and that > would already save all of us a huge amount of build time. > > This is not an easy task though, I know it, I know it cannot be done > in a matter of days or weeks, but it looks to me like it can be done > incrementally, one plugin at a time (the wiki also discusses > properties and profiles, which I hadn't thought about, but it seems to > me like this is not that different: take the plugin's configuration > into account when computing the work that needs to be done; the only > change needed at the core level would be tracking which plugins ran in > a previous build that won't run in the current one, it could then call > the plugin's "clean" goal if it exists at the beginning of the > build, > with its previous configuration, and otherwise clean the whole module) > > I might very well miss something obvious here though, as I'm merely > thinking out loud. Feel free to disregard my statements or contradict > me, I'm here to learn. > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
