Hi Vincent! I've now looked at the code and it appears that this is a relatively easy approach. It is still better than the current state. It's kind of my bullet A. (invoke a 'clean') but extends this idea to the own input sources.
This will work fine as long as you only strictly have default input paths and don't need additional input data. It will not work if you e.g. have multiple input paths to compile (multiple <execution> entries for the maven-compiler-plugin). It will also not help you suppressing a test run for projects which didn't get changed (no change in sources + dependencies for that module) - and that is actually the most expensive part of a build. LieGrue, strub ----- Original Message ----- > From: Vincent Latombe <vincent.lato...@gmail.com> > To: Maven Developers List <dev@maven.apache.org> > Cc: > Sent: Thursday, September 6, 2012 9:37 PM > Subject: Re: [incremental build] Detect leftovers from a previous build > > 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 <rmannibu...@gmail.com> > >> 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" <strub...@yahoo.de> > 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 <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 >> > >> > >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
