maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@gmail.com>
Subject Re: [incremental build] Detect leftovers from a previous build
Date Thu, 06 Sep 2012 18:59:49 GMT
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" <struberg@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message