I guess you missed me. I will not hand-pick which tests to run but run ALL
tests of a module if a SINGLE file got changed on the input
classpath/dependencies.
It's all or nothing to be on the safe side.
LieGrue,
strub
----- Original Message -----
> From: Romain Manni-Bucau <rmannibu...@gmail.com>
> To: Mark Struberg <strub...@yahoo.de>; Maven Developers List
> <dev@maven.apache.org>
> Cc:
> Sent: Friday, September 7, 2012 8:48 AM
> Subject: Re: [incremental build] Detect leftovers from a previous build
>
> How? If i change a class in main/java but the test is done by reflection
> youll miss it
> Le 7 sept. 2012 08:46, "Mark Struberg" <strub...@yahoo.de> a
> écrit :
>
>>
>>
>> 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
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
