What you talk about here is something that BuildContext should provide, if we stay with that. There's a scanner for changes and a deleteScanner. The really tricky thing is when one source file has more than one output/target file (like inner classes). The plugin needs some way of knowing what target file(s) to remove. I fit can't do that, then I guess the only option is to remove all the files it produced in the last execution.
/Anders On Thu, Sep 6, 2012 at 8:52 PM, Mark Struberg <strub...@yahoo.de> wrote: > > > 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