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" <[email protected]> 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 <[email protected]> > >To: Mark Struberg <[email protected]>; Maven Developers List < > [email protected]> > >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" <[email protected]> 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 <[email protected]> > >>> To: [email protected] > >>> 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: [email protected] > >>>> For additional commands, e-mail: [email protected] > >>>> > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: [email protected] > >>> For additional commands, e-mail: [email protected] > >>> > >> > >>--------------------------------------------------------------------- > >>To unsubscribe, e-mail: [email protected] > >>For additional commands, e-mail: [email protected] > >> > >> > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
