> openjpa-maven-plugin is actually an interesting case. openjpa:enhance,
> for example, will make it very hard or impossible for
> maven-compiler-plugin to decide if it needs to rebuild anything or not.
No, not a problem at all. It detects if the classes are already implementing
PersistenceCapable and don't touch them in that case.
> This breaks if BeanA and BeanA2 are in in different modules of the same
> reactor build. It really is necessary to track what inputs, i.e. sources
> and external dependencies, contributed to each generated .class to
> guarantee correct output.
Nope, is perfectly working already. Check the latest source from trunk.
If you have them in different modules then you can only have them linked in a
single direction anyway. And this direction gets properly detected now in 2.6.
LieGrue,
strub
----- Original Message -----
> From: Igor Fedorenko <i...@ifedorenko.com>
> To: dev@maven.apache.org
> Cc:
> Sent: Friday, September 7, 2012 11:44 PM
> Subject: Re: [incremental build] Detect leftovers from a previous build
>
>
>
> On 12-09-07 2:37 AM, Mark Struberg wrote:
>>> 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
>>
>
> openjpa-maven-plugin is actually an interesting case. openjpa:enhance,
> for example, will make it very hard or impossible for
> maven-compiler-plugin to decide if it needs to rebuild anything or not.
>
>> 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.
>>
>
> This breaks if BeanA and BeanA2 are in in different modules of the same
> reactor build. It really is necessary to track what inputs, i.e. sources
> and external dependencies, contributed to each generated .class to
> guarantee correct output.
>
> --
> Regards,
> Igor
>
>> 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
