Hi Romain, Should have prefaced the baseline ;)
I am now only focusing on plugin internal work inside a single maven pom module. See bullet B. in [1] The Maven Reactor code will trigger a 'clean' on the whole module if it detects an external dependency change / pom change / profile change / etc. See bullet A. [1] We are now really only focusing on the plugins itself as first step (aka B.). LieGrue, strub [1] https://cwiki.apache.org/confluence/display/MAVEN/Incremental+Builds >________________________________ > From: Romain Manni-Bucau <rmannibu...@gmail.com> >To: Mark Struberg <strub...@yahoo.de>; Maven Developers List ><dev@maven.apache.org> >Sent: Thursday, September 6, 2012 8:59 PM >Subject: Re: [incremental build] Detect leftovers from a previous build > > >What about browsing the build tree to detect the dep modules which needs to be >built (avoid a real clean which can cost really too much to make incr feature >useful)? Can be done in parallel and can be pretty fast >Le 6 sept. 2012 20:53, "Mark Struberg" <strub...@yahoo.de> a écrit : > > >> >>Hi! >> >>I had some idea for detecting stale changes in maven which is pretty generic >> >> >>The problem hits us if you compile BeanA and BeanA2 in a project where BeanA2 >>is using BeanA. >>On a >> >>$> mvn clean compile >> >>you will get both BeanA.class and BeanA2.class in target/classes >>Now delete BeanA.java >>Currently (2.6-SNAPSHOT) the maven-compiler-plugin only compiles all sources >>without doing any cleanup and thus BeanA.class will still remain in >>target/classes. >> >> >>That is clearly a bug as BeanA2 will be left broken, packaged into a broken >>jar, ... >> >> >> >>How can we avoid that? >> >>Simple answer: A plugin which doesnt support those cases by the underlying >>took (javac) must always first clean up the stuff it generated during the >>last invocation. >> >>How can we do that? >> >>step 1: Start a DirectoryScanner and get all files in target/classes. >>Remember this list! >> >> >>step 2: Run the compiler >> >> >>step 3: List all files in target/classes again and remove all files you found >>in step 1. You will end up with a list of all files generated by the >>compilation as result. >> >>step 4: Store this list into >>target/maven-status/maven-compiler-plugin/default/createdfiles.lst ('default' >>is the plugin execution. We need this in case we have multiple <executions>). >> >> >>On the next compile you just need to check if you have such a >>createdfiles.lst file and then first remove all the files listed in it as >>step 0. >>Then you can continue with step 1 from scratch. >> >>We could easily create a utility class for it which keeps the state with >>methods >> >>public class ChangeDetector /* TODO find better name */ >>{ >>File[] readPreviouslyDetectedFileList(File targetFile); >>void recordFiles(File baseDir) >>File[] detectNewFiles(); >>storeDetectedFileList(File targetFile) >>} >> >>This can e.g. also be used by the maven-resources-plugin to get rid of copied >>resources which got deleted from src/main/resources. >> >>Do you have a better idea? Any ideas for improving this? >>And a big question: how can I get hold of the current <execution> id in a >>plugin? >> >> >>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
