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
