Mailing-List: contact issues-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@maven.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Date: Wed, 2 Feb 2011 06:46:22 -0600 (CST)
From: "Kristian Rosenvold (JIRA)" <jira@codehaus.org>
To: issues@maven.apache.org
Message-ID: 
 <267297.964.1296650782363.JavaMail.haus-jira@codehaus01.managed.contegix.com>
In-Reply-To: 
 <29219931.13091.1293092397914.JavaMail.haus-jira@codehaus01.managed.contegix.com>
Subject: [jira] Issue Comment Edited: (MNG-4996) Maven3 parallel build fails
 occasionally for classpath problems.
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


    [ http://jira.codehaus.org/browse/MNG-4996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253819#action_253819 ] 

Kristian Rosenvold edited comment on MNG-4996 at 2/2/11 6:44 AM:
-----------------------------------------------------------------

Thanks a lot, that's two very good pieces of information.

Artifact resolution (and classpath building) is a fairly long-winded process in maven core. MavenProject#getCompileClasspathElements is probably a nice place to start looking. (MaveProject line 419).

I would be very interested in knowing if the build fails if you add the following few lines:

  public List<String> getCompileClasspathElements()
          throws DependencyResolutionRequiredException {
    List<String> list = new ArrayList<String>(getArtifacts().size() + 1);

    list.add(getBuild().getOutputDirectory());

    if (resolvedArtifacts.size() == 0)
    {
      throw new InvalidStateException("No resolved artifacts?");
    }

    ... rest of method ...
  }


(Check out from https://svn.apache.org/repos/asf/maven/maven-3/trunk, mvn clean install, zip file is in apache-maven/target/)


So if we could determine if resolvedArtifacts.size is 0 at the time you crash, we would effectively split the
entire code base in 2. Binary search is a powerful tool with these things. Make sure the patch works non-threaded first  ;)


I am assuming these are all non-public builds that I don't have access to ?

      was (Author: krosenvold):
    Thanks a lot, that's two very good pieces of information.

Artifact resolution (and classpath building) is a fairly long-winded process in maven core. MavenProject#getCompileClasspathElements is probably a nice place to start looking. (MaveProject line 419).

I would be very interested in knowing if the build files if you add the following few lines:

  public List<String> getCompileClasspathElements()
          throws DependencyResolutionRequiredException {
    List<String> list = new ArrayList<String>(getArtifacts().size() + 1);

    list.add(getBuild().getOutputDirectory());

    if (resolvedArtifacts.size() == 0)
    {
      throw new InvalidStateException("No resolved artifacts?");
    }

    ... rest of method ...
  }


(Check out from https://svn.apache.org/repos/asf/maven/maven-3/trunk, mvn clean install, zip file is in apache-maven/target/)

I do not think this should fail for most regular builds. 

So if we could determine if resolvedArtifacts.size is 0 at the time you crash, we would effectively split the
entire code base in 2. Binary search is a powerful tool with these things. Make sure the patch works non-threaded first  ;)


I am assuming these are all non-public builds ?
  
> Maven3 parallel build fails occasionally for classpath problems.
> ----------------------------------------------------------------
>
>                 Key: MNG-4996
>                 URL: http://jira.codehaus.org/browse/MNG-4996
>             Project: Maven 2 & 3
>          Issue Type: Bug
>          Components: Plugins and Lifecycle
>    Affects Versions: 3.0.1
>         Environment: maven 3.0.1, maven 3.0
>            Reporter: Kari J. Niemi
>            Assignee: Kristian Rosenvold
>
> In a multimodule (>120 modules) maven build, the compiler plug-in would seem to fail in creating a correct class-path every now and then.
> Instead of this entry in maven -X logs for a single module build:
> ----
> [DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile' with basic configurator -->
> ..
> [DEBUG]   (f) classpathElements = [/home/karniemi/"mymodulepath"/target/classes, /home/karniemi/.m2/repository/org/apache/servicemix/servicemix-utils/1.2.0/servicemix-utils-1.2.0.jar, /home/karniemi/.m2/repository/org/apache/geronimo/specs/geronimo-stax-api_1.0_spec/1.0.1/geronimo-stax-api_1.0_spec-1.0.1.jar, /home/karniemi/.m2/repository/org/codehaus/woodstox/wstx-asl/3.2.6/wstx-asl-3.2.6.jar, /home/karniemi/.m2/repository/org/apache/servicemix/specs/org.apache.servicemix.specs.jbi-api-1.0/1.4.0/org.apache.servicemix.specs.jbi-api-1.0-1.4.0.jar, /home/karniemi/.m2/repository/org/apache/geronimo/specs/geronimo-activation_1.1_spec/1.0.2/geronimo-activation_1.1_spec-1.0.2.jar, /home/karniemi/.m2/repository/log4j/log4j/1.2.14/log4j-1.2.14.jar]
> ----
> every now and then I get this in the parallel build:
> ----
> [DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile' with basic configurator -->
> ...
> [DEBUG]   (f) classpathElements = [/home/karniemi/"mymodulepath"/target/classes]
> ----
> And of course the compilation fails because none of the dependencies are added to the classpath. Sometimes it goes fine in the multi-module build, but every now and then it fails for this.
> In both maven runs I can see that the dependencies are resolved fine:
> ----------
> [DEBUG] "mymodule":jar:DYNAMIC-SNAPSHOT
> [DEBUG]    junit:junit:jar:4.7:test
> [DEBUG]    org.apache.servicemix:servicemix-utils:jar:1.2.0:provided
> [DEBUG]       org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1:provided
> [DEBUG]       org.codehaus.woodstox:wstx-asl:jar:3.2.6:provided
> [DEBUG]       org.apache.servicemix.specs:org.apache.servicemix.specs.jbi-api-1.0:jar:1.4.0:provided (scope managed from compile) (version managed from 1.1.0)
> [DEBUG]          org.apache.geronimo.specs:geronimo-activation_1.1_spec:jar:1.0.2:provided
> [DEBUG]    log4j:log4j:jar:1.2.14:provided
> -----------
>  
> The  pluginArtifactMap looks like this:
> --------------------
> [DEBUG]   (s) pluginArtifactMap = {org.apache.maven.plugins:maven-surefire-plugin=org.apache.maven.plugins:maven-surefire-plugin:maven-plugin:2.6:, org.apache.maven.surefire:surefire-booter=org.apache.maven.surefire:surefire-booter:jar:2.6:compile, org.apache.maven.surefire:surefire-api=org.apache.maven.surefire:surefire-api:jar:2.6:compile, org.apache.maven.surefire:maven-surefire-common=org.apache.maven.surefire:maven-surefire-common:jar:2.6:compile, org.apache.maven.shared:maven-common-artifact-filters=org.apache.maven.shared:maven-common-artifact-filters:jar:1.2:compile, org.codehaus.plexus:plexus-utils=org.codehaus.plexus:plexus-utils:jar:2.0.5:compile, junit:junit=junit:junit:jar:3.8.1:compile, org.apache.maven.reporting:maven-reporting-api=org.apache.maven.reporting:maven-reporting-api:jar:2.0.9:compile}
> --------------------
> I'm really using jbi-maven-plugin for most of the modules, and that plugin binds the other plugins -also the compiler-plugin -to maven life-cycle phases.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira