Answers inside.
LieGrue,
strub
----- Original Message -----
> From: Anders Hammar <and...@hammar.net>
> To: Maven Developers List <dev@maven.apache.org>; Mark Struberg
> <strub...@yahoo.de>
> Cc:
> Sent: Thursday, September 6, 2012 9:51 PM
> Subject: Re: [incremental build] Detect leftovers from a previous build
>
> 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 BuildContext looks indeed like a good candidate!
> 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 know, that + the cross dependencies which are almost unpredictable (would
require to parse and evaluate all sources). I opted for recompiling all sources
because of that.
> I fit can't do that, then I
> guess the only option is to remove all the files it produced in the
> last execution.
Yes, that was this algorithm should make possible.
The problem is that we cannot simply delete all files in target/classes,
because parts of it might have been created by other plugins (e.g. the resource
processing).
>
> /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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
