Thomas Broyer, Enrico Olivelli, I consider the whole directory where the module's pom.xml resides, excluding the target/ dir, as the input, and the final module artifacts as the output.
Even if some plugins allow sources outside the pom.xml's directory (out of curiosity, is it possible?), it is an acceptable restriction on project structure, IMO. The version hash approach I described may cause some redundant work. For example, if only dependencies changed, most often only re-testing is needed, re-compilation and re-packaging are not necessary (unless your dependency generates or instruments code at compilation time, or you package an uberjar or war, which includes dependency artifacts). But for stability better to compromise, accepting some redundant work, than go into such complexities as intermediate results of individual plugins, distinguishing test and prod sources, types of dependencies. Even the simplest hash versioning can potentially give significant speedups for large multi-module projects. I've spent this weekend trying to create a script for such version hashes. But haven't completed it (yet), due to various obstacles in maven behaviour (impossible to use property expression in the project/version element; the dependency:tree goal requires artifact of the current version to be present in the ~/.m2 folder, although it doesn't look into the artifact content, so it can even be a fake artifact). Maybe someday I'll have more progress. Best regards, - Anton --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
