Support 'weave' parallel build

[GregDomjan]

Similar to issues with #71 the experimental maven parallel weave build requires knowledge of compile time artifacts to continue parallel dependencies.

mvn -T4W test should complete the compilation similarly to mvn -T4 compile

http://docs.codehaus.org/display/MAVENUSER/Weave+mode+characteristics

[GregDomjan]

[WARNING] [WARNING] * Your build is requesting parallel execution, but project [WARNING] * contains the following plugin(s) that are not marked as [WARNING] * @threadSafe to support parallel building. [WARNING] * While this /may/ work fine, please look for plugin updates [WARNING] * and/or request plugins be made thread-safe. [WARNING] * If reporting an issue, report it against the plugin in [WARNING] * question, not against maven-core [WARNING] *

[dscho]

@GregDomjan I am unfamiliar with that flag... or with weave for that matter...

[GregDomjan]

@dscho Parallel build (-T option) was added in maven 3, part of that was a new form of parallel build called weave (W arg) which would attempt to start building modules sooner when modules reach end of compilation phase and end of test phase

• standard parallel builds modules that have all dependencies fully satisfied completed to selected phase
• weave build will allow projects to start building when their dependencies have reached end of compile phase, allowing compilation of follow on items while a build is still running test and package.

This depends on changes similar to issue #71 so that dependent projects will be able to find the content to compile against. There are also other issues to be resolved such as thread safety, overlapped nar unpack to common folder and ?

[GregDomjan]

https://cwiki.apache.org/confluence/display/MAVEN/Parallel+builds+in+Maven+3

Mojo thread safety assertion checklist Sometimes it can be hard to determine if a plugin and the underlying libraries are thread-safe, so when adding @threadSafe the following checklist can be used:

• Check all static fields/variables in plugin/plugin code are not subject to threading problems. You might want to pay special attention to static member variables of the subclasses of "java.text.Format" (NumeberFormat, DateFormat etc), most of which are not threadsafe and cannot be shared as static variables.
• Check any plexus components.xml; if the components defined are singletons they need to be threadsafe.
• Check for presence of known tainted libraries.
• Check thread safety of any other third party libraries. This last item can be a bit hard, but inquiries on mailing lists can get you a long way. This checklist qualifies for a "simple thread safety" review of a mojo.

Known dependencies appear to be ok http://jira.codehaus.org/browse/MSHARED-148 Due to PLXCOMP-149, PLXUTILS-130 and PLXUTILS-131, the following libraries must be updated to at least the specified versions: plexus-utils version 2.0.5 or higher (already selected) plexus-io version 1.0 or higher (only used by plexus archiver) plexus-archiever version 1.0 or higher (already selected)

maven-archiver 2.4.1 or higher - unused as far as I can see Using dependency:tree -Dverbose -Dincludes=org.apache.maven:maven-archiver

Code issues CPPTasks Has a variety of static class variables, needs more detail check if they are all final or might actually change.

NarProperties has singleton instance, not good for multi thread

private static NarProperties instance;

StreamGobbler needs check

private static final class StreamGobbler

[dscho]

Is it just me, or are we already using weave correctly? I was recently surprised to see that one of my own projects was built using a nice progress counter. OTOH I could not tell whether it was building in parallel because it was too fast.

[dscho]

I guess I mistook the Ant way to do parallel builds for weave builds.

But I fear that I really want to close this ticket. It seems not to go anywhere.

[GregDomjan]

Still an issue for us though I've had no time to work on anything maven for a while. I believe issue #122 also relates to a part of this.

[dscho]

I believe issue #122 also relates to a part of this.

@GregDomjan quite possible.

Still an issue for us though

I am assigning this ticket to you, then.

[ctrueden]

Let's discuss on the maven-nar list.