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
