Ok so bad thread but the not stays valid. Triggering a clean is not a
solution for me
Le 6 sept. 2012 21:05, "Mark Struberg" <strub...@yahoo.de> a écrit :

> Hi Romain,
>
> Should have prefaced the baseline ;)
>
> I am now only focusing on plugin internal work inside a single maven pom
> module. See bullet B. in [1]
>
> The Maven Reactor code will trigger a 'clean' on the whole module if it
> detects an external dependency change / pom change / profile change / etc.
> See bullet A. [1]
>
>
> We are now really only focusing on the plugins itself as first step (aka
> B.).
>
> LieGrue,
> strub
>
>
> [1] https://cwiki.apache.org/confluence/display/MAVEN/Incremental+Builds
>
>
> >________________________________
> > From: Romain Manni-Bucau <rmannibu...@gmail.com>
> >To: Mark Struberg <strub...@yahoo.de>; Maven Developers List <
> dev@maven.apache.org>
> >Sent: Thursday, September 6, 2012 8:59 PM
> >Subject: Re: [incremental build] Detect leftovers from a previous build
> >
> >
> >What about browsing the build tree to detect the dep modules which needs
> to be built (avoid a real clean which can cost really too much to make incr
> feature useful)? Can be done in parallel and can be pretty fast
> >Le 6 sept. 2012 20:53, "Mark Struberg" <strub...@yahoo.de> a écrit :
> >
> >
> >>
> >>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
>
>

Reply via email to