Hi Kristian!
> How will this help if I delete an old file, one that simply hasnt been
> changed?
This is applicable for all plugins which process all input files, like the
compiler plugin does.
In the case you mentioned we will first delete all *.class files created by the
previous run (including the class file of your now deleted file) and then do a
full recompile which (as this file no longer exists) will not crete this class
file again.
> Also, won't the list just grow infinitely ?
No, it will only contain the list of files created by the last plugin run for
the very execution-id. Of course this tool is only useful (and shall be only
used) for plugins which re-create the output over again if a change got
detected.
Again: The downside with all that approach is that all plugins must support
incremental builds.
The easy alternative would be to force a clean if any file in src/ got changed.
> re executions; search for "a tribute to Linus Torvalds"
will do.
LieGrue,
strub
----- Original Message -----
> From: Kristian Rosenvold <kristian.rosenv...@zenior.no>
> To: Maven Developers List <dev@maven.apache.org>
> Cc:
> Sent: Friday, September 7, 2012 7:09 AM
> Subject: Re: [incremental build] Detect leftovers from a previous build
>
> How will this help if I delete an old file, one that simply hasnt been
> changed? Also, won't the list just grow infinitely ?
>
> re executions; search for "a tribute to Linus Torvalds" in the
> surefire source to find a really neat workaround that solves several
> of your other problems..
>
> Kristian
>
> Den 6. sep. 2012 kl. 20:53 skrev Mark Struberg <strub...@yahoo.de>:
>
>>
>>
>> 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
