[jira] Updated: (MPMULTIPROJECT-16) multiproject:site fails in multiproject:site-init when projects are interdependent

["Lukas Theussl (JIRA)" <ji...@codehaus.org>]

     [ http://jira.codehaus.org/browse/MPMULTIPROJECT-16?page=all ]

Lukas Theussl updated MPMULTIPROJECT-16:
----------------------------------------

    Description: 
The multiproject:site goal calls multiproject:site-init to initialize the list of projects included in the current multiproject configuration, to keep from having to repeatedly assemble this collection. It uses the reactor to handle this, running it without any specified goal, merely to collect the project list. 

The trouble arises when any project within that set depends on another project within the set, and none of the project jars have been installed and/or deployed yet. In this case, when reactor tries to run, it attempts to resolve all dependencies for each project it includes, even if it's not actually running any goals on these projects. Obviously, in this case the projects' dependencies cannot be completely resolved, and the build fails. Dependency resolution is an unnecessary step for the intent of the multiproject:site-init goal, and therefore should not be a limiting factor during the goal's execution.

Therefore, I propose the following: modify the reactor tag to include two more attributes. These should be collectOnly and collectionVar. The first will allow the reactor to avoid execution of the project goals (default or otherwise) when the intent is merely to collect a set of projects. The second allows us to have control over the name of the project collection within the context, instead of trusting that the name "reactorProjects" will never change.

Once this is accomplished, we will need to modify the multiproject:site-init's invocation of the reactor tag to look like:

    <maven:reactor
      basedir="${maven.multiproject.basedir}"
      banner="Gathering project list"
      includes="${maven.multiproject.includes}"
      excludes="${maven.multiproject.excludes}"
      postProcessing="true"
      ignoreFailures="${maven.multiproject.ignoreFailures}"
      collectOnly="true"
      collectionVar="reactorProject"
    />

This will accomplish two important goals. First, we will not be dependent upon a side effect of the reator's execution (the binding of "reactorProjects" within the context), and second we will not be forced to resolve the projects included in the reactor's scope if all we want to do is collect the project set for later use.

I am attaching a patch to this issue to handle the multiproject modifications for this task, and will post an associated issue in the maven project to accomplish the modifications to the reactor tag. The maven issue id will be documented later.

  was:
The multiproject:site goal calls multiproject:site-init to initialize the list of projects included in the current multiproject configuration, to keep from having to repeatedly assemble this collection. It uses the reactor to handle this, running it without any specified goal, merely to collect the project list. 

The trouble arises when any project within that set depends on another project within the set, and none of the project jars have been installed and/or deployed yet. In this case, when reactor tries to run, it attempts to resolve all dependencies for each project it includes, even if it's not actually running any goals on these projects. Obviously, in this case the projects' dependencies cannot be completely resolved, and the build fails. Dependency resolution is an unnecessary step for the intent of the multiproject:site-init goal, and therefore should not be a limiting factor during the goal's execution.

Therefore, I propose the following: modify the reactor tag to include two more attributes. These should be collectOnly and collectionVar. The first will allow the reactor to avoid execution of the project goals (default or otherwise) when the intent is merely to collect a set of projects. The second allows us to have control over the name of the project collection within the context, instead of trusting that the name "reactorProjects" will never change.

Once this is accomplished, we will need to modify the multiproject:site-init's invocation of the reactor tag to look like:

    <maven:reactor
      basedir="${maven.multiproject.basedir}"
      banner="Gathering project list"
      includes="${maven.multiproject.includes}"
      excludes="${maven.multiproject.excludes}"
      postProcessing="true"
      ignoreFailures="${maven.multiproject.ignoreFailures}"
      collectOnly="true"
      collectionVar="reactorProject"
    />

This will accomplish two important goals. First, we will not be dependent upon a side effect of the reator's execution (the binding of "reactorProjects" within the context), and second we will not be forced to resolve the projects included in the reactor's scope if all we want to do is collect the project set for later use.

I am attaching a patch to this issue to handle the multiproject modifications for this task, and will post an associated issue in the maven project to accomplish the modifications to the reactor tag. The maven issue id will be documented later.

    Fix Version: 1.5

> multiproject:site fails in multiproject:site-init when projects are interdependent
> ----------------------------------------------------------------------------------
>
>          Key: MPMULTIPROJECT-16
>          URL: http://jira.codehaus.org/browse/MPMULTIPROJECT-16
>      Project: maven-multiproject-plugin
>         Type: Bug
>  Environment: all
>     Reporter: John Casey
>      Fix For: 1.5
>  Attachments: multiproject-gather-dependency-defer-fix.patch
>
> Original Estimate: 1 hour
>         Remaining: 1 hour
>
> The multiproject:site goal calls multiproject:site-init to initialize the list of projects included in the current multiproject configuration, to keep from having to repeatedly assemble this collection. It uses the reactor to handle this, running it without any specified goal, merely to collect the project list. 
> The trouble arises when any project within that set depends on another project within the set, and none of the project jars have been installed and/or deployed yet. In this case, when reactor tries to run, it attempts to resolve all dependencies for each project it includes, even if it's not actually running any goals on these projects. Obviously, in this case the projects' dependencies cannot be completely resolved, and the build fails. Dependency resolution is an unnecessary step for the intent of the multiproject:site-init goal, and therefore should not be a limiting factor during the goal's execution.
> Therefore, I propose the following: modify the reactor tag to include two more attributes. These should be collectOnly and collectionVar. The first will allow the reactor to avoid execution of the project goals (default or otherwise) when the intent is merely to collect a set of projects. The second allows us to have control over the name of the project collection within the context, instead of trusting that the name "reactorProjects" will never change.
> Once this is accomplished, we will need to modify the multiproject:site-init's invocation of the reactor tag to look like:
>     <maven:reactor
>       basedir="${maven.multiproject.basedir}"
>       banner="Gathering project list"
>       includes="${maven.multiproject.includes}"
>       excludes="${maven.multiproject.excludes}"
>       postProcessing="true"
>       ignoreFailures="${maven.multiproject.ignoreFailures}"
>       collectOnly="true"
>       collectionVar="reactorProject"
>     />
> This will accomplish two important goals. First, we will not be dependent upon a side effect of the reator's execution (the binding of "reactorProjects" within the context), and second we will not be forced to resolve the projects included in the reactor's scope if all we want to do is collect the project set for later use.
> I am attaching a patch to this issue to handle the multiproject modifications for this task, and will post an associated issue in the maven project to accomplish the modifications to the reactor tag. The maven issue id will be documented later.

-- 
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


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org