Ok, not the best but sure
Le 7 sept. 2012 08:52, "Mark Struberg" <strub...@yahoo.de> a écrit :
> 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
>
>
