Romain, we can perfectly do that!
We just need to check whether anything on the input classpath got changed
(jars, classes, etc).
Of course there are cases where you like to manually re-run tests over again.
For those cases we would need to introduce a 'force' flag somehow.
LieGrue,
strub
>________________________________
> From: Romain Manni-Bucau <rmannibu...@gmail.com>
>To: Mark Struberg <strub...@yahoo.de>; Maven Developers List
><dev@maven.apache.org>
>Sent: Friday, September 7, 2012 8:41 AM
>Subject: Re: [incremental build] Detect leftovers from a previous build
>
>
>You cant do it dor surefire. Tests are sometimes done by reflection and you
>cant ask a dep tree by test.in real world.
>Le 7 sept. 2012 08:37, "Mark Struberg" <strub...@yahoo.de> a écrit :
>
>> I may be missing something, but if all plugins implement this logic,
>>> how it will be different from implicitly doing "clean" during each
>>> build?
>>
>>There is actually a huge difference
>>
>>a.) yes, there are quite a few of such plugins which do not need this. Think
>>about sql-maven-plugin, openjpa-maven-plugin, etc
>>
>>b.) A plugin will only delete all it's output from a previous invocation
>>AFTER it detects that it really needs to do something! If there is e.g. no
>>.java file which is newer than it's corresponding .class and no .java file
>>got added or removed, then the whole compilation doesn't get triggered. Of
>>course it's currently (without such a helper) hard to detect if a file got
>>removed from src/...
>>
>>A very simple hack would be to create a DirectoryScanner and store / later
>>compare the md5 of all ./src files and trigger the clean lifecycle if that
>>got changed. That seems to be the stuff the incremental-build-plugin does.
>>That would be better than nothing, but not sure if it would be sufficient.
>>I'd at least try to get rid of unnecessary surefire executions.
>>
>>LieGrue,
>>strub
>>
>>
>>
>>
>>----- Original Message -----
>>> From: Igor Fedorenko <i...@ifedorenko.com>
>>> To: dev@maven.apache.org
>>> Cc:
>>> Sent: Friday, September 7, 2012 4:14 AM
>>> Subject: Re: [incremental build] Detect leftovers from a previous build
>>>
>>> I may be missing something, but if all plugins implement this logic,
>>> how it will be different from implicitly doing "clean" during each
>>> build? Or, put differently, are there plugins that do not need to clean
>>> their previous output to be absolutely sure they properly handle
>>> incremental rebuilds?
>>>
>>> --
>>> Regards,
>>> Igor
>>>
>>> On 12-09-06 2:52 PM, Mark Struberg 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
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
