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
>
>
