[
https://jira.codehaus.org/browse/MCOMPILER-170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=297902#comment-297902
]
Falko Modler edited comment on MCOMPILER-170 at 5/4/12 5:04 PM:
----------------------------------------------------------------
Ok, so in my opinion that means:
- the plugin is *not threadsafe by default* anymore which means 2.4 breaks
backward compatibility to some extend
- the documentation should clearly point out that fork needs to be turned on
(default is off/false) when using the parallel build feature
see also:
http://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html -> "The
goal is thread-safe and supports parallel builds."
- MCOMPILER-166 brings a *performance gain for single threaded builds only* but
results in a *performance hit for parallel builds* because the forking causes
more overhead
Seriously, medium to large scale projects *will* have many sub-modules (at
least that's what I have seen in many projects where I work) so it is more than
probable that the parallel build feature will be used. In my current project we
save a lot of valuable time by using this feature.
With that in mind, it is rather disappointing that version 2.4. of the plugin
will actually slow down parallel builds.
Please reconsider the changes made by MCOMPILER-166!
You could at least introduce a switch to enable/disable the caching introduced
by MCOMPILER-166.
Personally, I think this caching should be off by default to ensure backward
compatibility for parallel builds.
Edit:
Just realized that above-mentioned flag would have to be passed to that
"external" plexus component which means this will be harder achieve.
But still - as outlined above - the current situation is really not
satisfactory.
was (Author: famod):
Ok, so in my opinion that means:
- the plugin is *not threadsafe by default* anymore which means 2.4 breaks
backward compatibility to some extend
- the documentation should clearly point out that fork needs to be turned on
(default is off/false) when using the parallel build feature
see also:
http://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html -> "The
goal is thread-safe and supports parallel builds."
- MCOMPILER-166 brings a *performance gain for single threaded builds only* but
results in a *performance hit for parallel builds* because the forking causes
more overhead
Seriously, medium to large scale projects *will* have many sub-modules (at
least that's what I have seen in many projects where I work) so it is more than
probable that the parallel build feature will be used. In my current project we
save a lot of valuable time by using this feature.
With that in mind, it is rather disappointing that version 2.4. of the plugin
will actually slow down parallel builds.
Please reconsider the changes made by MCOMPILER-166!
You could at least introduce a switch to enable/disable the caching introduced
by MCOMPILER-166.
Personally, I think this caching should be off by default to ensure backward
compatibility for parallel builds.
> Regression: Compiler Plugin fails when building with multiple threads (-T...)
> -----------------------------------------------------------------------------
>
> Key: MCOMPILER-170
> URL: https://jira.codehaus.org/browse/MCOMPILER-170
> Project: Maven 2.x Compiler Plugin
> Issue Type: Bug
> Affects Versions: 2.4
> Environment: Windows 7 x64, JDK 1.6.0_31, Maven 3.0.4
> Reporter: Falko Modler
> Priority: Critical
>
> I just tried building my current project which is rather large and has many
> sub-modules.
> With version 2.3.2 (and below) of the plugin I was able to build the whole
> project with multiple threads, let's say:
> {{mvn clean compile -T4}}
> Version 2.4 fails with random errors when using this command line!
> Errors include missing closing brackets, "cannot find symbol" and so on. It's
> also not always the same module where the errors occur.
> A single-threaded build with:
> {{mvn clean compile}}
> *completes just fine*!
> Unfortunately I cannot upload my project for copyright reasons.
> So for me it looks like a "classic" concurrency problem. Maybe side effect of
> MCOMPILER-166?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
