[
https://jira.codehaus.org/browse/MNG-5750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361074#comment-361074
]
Alexander Ashitkin commented on MNG-5750:
-----------------------------------------
At the moment i suppose the problem is with
MojoExecutor#ensureDependenciesAreResolved, this place:
{code}
for ( MavenProject projectToResolve : projectsToResolve )
{
projectToResolve.setArtifactFilter( artifactFilter );
}
{code}
if intention is to reset filter before the resolved project build starts - it
doesnt work, the projects are being built concurrently.
I applied a local patch to workaround the issue and will come with results
later:
{code}
ArtifactFilter artifactFilter = getArtifactFilter( mojoDescriptor );
List<MavenProject> projectsToResolve =
LifecycleDependencyResolver.getProjects(
session.getCurrentProject(), session,
mojoDescriptor.isAggregator() );
boolean skipFilterOnResolved =
Boolean.getBoolean("maven.MNG-5750.skipFilterOnResolved");
if (!skipFilterOnResolved) {
for ( MavenProject projectToResolve : projectsToResolve )
{
projectToResolve.setArtifactFilter( artifactFilter );
}
} else {
// this bracnh is triggered as workaround
System.err.println("recursive projectToResolve.setArtifactFilter(
artifactFilter ) skipped maven.MNG-5750.skipFilterOnResolved=true");
session.getCurrentProject().setArtifactFilter(artifactFilter);
}
{code}
thank you
> Sporadic failures in concurrent build
> -------------------------------------
>
> Key: MNG-5750
> URL: https://jira.codehaus.org/browse/MNG-5750
> Project: Maven
> Issue Type: Bug
> Components: General
> Affects Versions: 3.1.1, 3.2.1, 3.2.2, 3.2.5
> Environment: SLES 3.0.80-0.7-default SMP x86_64 GNU/Linux Oracle
> HotSpot JDK 7u25
> windows server 2008 x64 Oracle HotSpot JDK 7u65/8u25
> Reporter: Alexander Ashitkin
> Priority: Critical
>
> We have a large project of 300+ modules which regularly fails with different
> kind of errors in different places. The issue is reliably reproduced with
> parallel build and is not happens in single threaded. The optimal concurrency
> level for our project ~10 threads. At this level ~%20 of builds fail. To
> workaround the issue we reduced concurrency to 4 in development builds and
> reverted production build to 1 thread.
> Main point of failures:
> # Surefire ClassNotFound. Reported and investigated in SUREFIRE-1132. Points
> to a problem with MavenProject#getArtifacts - empty set unexpectedly returned.
> # Compiler - unexpected failure because of incorrect classpath (literally all
> dependencies are not on the classpath), like: {code}
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[3,30] package ...
> does not exist
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[4,30] package ...
> does not exist
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[8,25] package ...
> does not exist
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[9,21] package
> org.joda.time does not exist
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[11,37] package
> com.google.common.base does not exist
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[11,1] static
> import only from classes and interfaces
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[12,37] package
> com.google.common.base does not exist
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[12,1] static
> import only from classes and interfaces
> {code}
> # Jar - unexpected NPE. Reported with stack traces in MJAR-192. (assembly
> plusgin seems to be also affected)
> At this point the issue looks like problem with MavenProject#getArtifacts in
> concurrent builds.
> To help with the issue im happy to implement or evaluate any custom assembly
> to trace this down. Unfortunately i cannot submit my project - it is
> proprietary.
> Thanks in advance, Alexander
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
