Hi, the topic has been raised a long time ago, someone even wrote a plugin to try to address this problem. see http://maven-incremental-build.java.net/site/index.html
Vincent 2012/9/6 Romain Manni-Bucau <[email protected]> > Ok so bad thread but the not stays valid. Triggering a clean is not a > solution for me > Le 6 sept. 2012 21:05, "Mark Struberg" <[email protected]> a écrit : > > > 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 <[email protected]> > > >To: Mark Struberg <[email protected]>; Maven Developers List < > > [email protected]> > > >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" <[email protected]> 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: [email protected] > > >>For additional commands, e-mail: [email protected] > > >> > > >> > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > >
