[ 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
