[
https://jira.codehaus.org/browse/MASSEMBLY-600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MASSEMBLY-600:
--------------------------------------
Description:
In two multi-module project setups like the ones attached to the bug where:
{noformat}
root-aggregator (type=pom -> aggregator as well as extension)
|
|___(module)___ root-type1 (type=pom -> only for extension)
|
|___(module)___ assembler (type=pom -> uses maven-assembly-plugin with
shared-assembly-defs dependency)
|
|___(module)___ shared-assembly-defs (type=jar)
|
|____/src/main/resources/assemblies/assemblydefinition.xml
|
|____________ moduleSets ->
moduleSet (useAllReactorProjects=true) -> binaries
{noformat}
and another multi-module project with these characteristics:
{noformat}
child-aggregator (parent=root-aggregator for inheritance)
|
|____(module)___ child-assembler (parent=root.assembler for inheritance of
maven-assembly-plugin)
|
|____(module)___ child-type1 (parent=root-type1 for inheritance of
dependencies and plugins config)
{noformat}
The assembly zip in the child-aggregator/child-assembler project does not
contain the jar from child-type1 even though it is in the reactor projects
list...
I was able to trace the problem back to the class:
org.apache.maven.plugin.assembly.archive.phase.ModuleSetAssemblyPhase
method:
{code:java}
public static Set<MavenProject> getModuleProjects( final ModuleSet moduleSet,
final
AssemblerConfigurationSource configSource,
final Logger logger )
{code}
where the code reads:
{code:java}
if ( moduleSet.isUseAllReactorProjects() ) <--- we are in this case
because our assembly descriptor says so!
{
if ( !moduleSet.isIncludeSubModules() ) <-- In the case that shows
the bug this is not defined - default is true
{
moduleProjects = new LinkedHashSet<MavenProject>(
configSource.getReactorProjects() );
}
project = configSource.getReactorProjects().get( 0 ); <-- first
project in the reactor order gets chosen... why?
}
if ( moduleProjects == null )
{
try
{
moduleProjects =
ProjectUtils.getProjectModules( project,
configSource.getReactorProjects(),
moduleSet.isIncludeSubModules(), logger );
<-- here if finds all modules of "first in the reactor"
project
}
catch ( final IOException e )
{
throw new ArchiveCreationException( "Error retrieving
module-set for project: " + project.getId()
+ ": " + e.getMessage(), e );
}
}
{code}
If on the other hand (for working around the issue) one sets
includeSubModules=false in the assembly definition (just uncomment in the
"assembly-share" project assembly definition in the submitted example), then
the reactor projects are used as per the top aggregator and everything goes
well, except for the fact that another warning shows up saying that
includeSubModules=false and useAllReactorProjects=true are incompatible and
will be ignored (this combination is not ignored but the warning does make
sense, though!)
This is related to the fact that in the child-aggregator project and modules,
there is no dependency between the child-type1 project and the
child-aggregator, which means the Reactor will order the builds as
child-type1, child-assembler, child-aggregator
but the code actually selects child-type1 as the "project" to determine modules
from.
was:
In two multi-module project setups like the ones attached to the bug where:
root-aggregator (type=pom -> aggregator as well as extension)
|
|___(module)___ root-type1 (type=pom -> only for extension)
|
|___(module)___ assembler (type=pom -> uses maven-assembly-plugin with
shared-assembly-defs dependency)
|
|___(module)___ shared-assembly-defs (type=jar)
|
|____/src/main/resources/assemblies/assemblydefinition.xml
|
|____________ moduleSets ->
moduleSet (useAllReactorProjects=true) -> binaries
and another multi-module project with these characteristics:
child-aggregator (parent=root-aggregator for inheritance)
|
|____(module)___ child-assembler (parent=root.assembler for inheritance of
maven-assembly-plugin)
|
|____(module)___ child-type1 (parent=root-type1 for inheritance of
dependencies and plugins config)
The assembly zip in the child-aggregator/child-assembler project does not
contain the jar from child-type1 even though it is in the reactor projects
list...
I was able to trace the problem back to the class:
org.apache.maven.plugin.assembly.archive.phase.ModuleSetAssemblyPhase
method:
public static Set<MavenProject> getModuleProjects( final ModuleSet moduleSet,
final
AssemblerConfigurationSource configSource,
final Logger logger )
where the code reads:
if ( moduleSet.isUseAllReactorProjects() ) <--- we are in this case
because our assembly descriptor says so!
{
if ( !moduleSet.isIncludeSubModules() ) <-- In the case that shows
the bug this is not defined - default is true
{
moduleProjects = new LinkedHashSet<MavenProject>(
configSource.getReactorProjects() );
}
project = configSource.getReactorProjects().get( 0 ); <-- first
project in the reactor order gets chosen... why?
}
if ( moduleProjects == null )
{
try
{
moduleProjects =
ProjectUtils.getProjectModules( project,
configSource.getReactorProjects(),
moduleSet.isIncludeSubModules(), logger );
<-- here if finds all modules of "first in the reactor"
project
}
catch ( final IOException e )
{
throw new ArchiveCreationException( "Error retrieving
module-set for project: " + project.getId()
+ ": " + e.getMessage(), e );
}
}
If on the other hand (for working around the issue) one sets
includeSubModules=false in the assembly definition (just uncomment in the
"assembly-share" project assembly definition in the submitted example), then
the reactor projects are used as per the top aggregator and everything goes
well, except for the fact that another warning shows up saying that
includeSubModules=false and useAllReactorProjects=true are incompatible and
will be ignored (this combination is not ignored but the warning does make
sense, though!)
This is related to the fact that in the child-aggregator project and modules,
there is no dependency between the child-type1 project and the
child-aggregator, which means the Reactor will order the builds as
child-type1, child-assembler, child-aggregator
but the code actually selects child-type1 as the "project" to determine modules
from.
> ModuleSets incorrectly detected with useAllReactorProjects while aggregating
> modules with parents differing from the aggregator
> -------------------------------------------------------------------------------------------------------------------------------
>
> Key: MASSEMBLY-600
> URL: https://jira.codehaus.org/browse/MASSEMBLY-600
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
> Affects Versions: 2.2, 2.2.2, 2.3
> Environment: Maven 2.2.1
> Reporter: José Pedro Pereira
> Priority: Blocker
> Attachments: child-aggregator.zip
>
>
> In two multi-module project setups like the ones attached to the bug where:
> {noformat}
> root-aggregator (type=pom -> aggregator as well as extension)
> |
> |___(module)___ root-type1 (type=pom -> only for extension)
> |
> |___(module)___ assembler (type=pom -> uses maven-assembly-plugin with
> shared-assembly-defs dependency)
> |
> |___(module)___ shared-assembly-defs (type=jar)
> |
>
> |____/src/main/resources/assemblies/assemblydefinition.xml
> |
> |____________ moduleSets ->
> moduleSet (useAllReactorProjects=true) -> binaries
> {noformat}
> and another multi-module project with these characteristics:
> {noformat}
> child-aggregator (parent=root-aggregator for inheritance)
> |
> |____(module)___ child-assembler (parent=root.assembler for inheritance
> of maven-assembly-plugin)
> |
> |____(module)___ child-type1 (parent=root-type1 for inheritance of
> dependencies and plugins config)
> {noformat}
>
> The assembly zip in the child-aggregator/child-assembler project does not
> contain the jar from child-type1 even though it is in the reactor projects
> list...
> I was able to trace the problem back to the class:
> org.apache.maven.plugin.assembly.archive.phase.ModuleSetAssemblyPhase
> method:
> {code:java}
> public static Set<MavenProject> getModuleProjects( final ModuleSet moduleSet,
> final
> AssemblerConfigurationSource configSource,
> final Logger logger )
> {code}
> where the code reads:
> {code:java}
> if ( moduleSet.isUseAllReactorProjects() ) <--- we are in this case
> because our assembly descriptor says so!
> {
> if ( !moduleSet.isIncludeSubModules() ) <-- In the case that
> shows the bug this is not defined - default is true
> {
> moduleProjects = new LinkedHashSet<MavenProject>(
> configSource.getReactorProjects() );
> }
> project = configSource.getReactorProjects().get( 0 ); <-- first
> project in the reactor order gets chosen... why?
> }
> if ( moduleProjects == null )
> {
> try
> {
> moduleProjects =
> ProjectUtils.getProjectModules( project,
> configSource.getReactorProjects(),
>
> moduleSet.isIncludeSubModules(), logger );
> <-- here if finds all modules of "first in the reactor"
> project
> }
> catch ( final IOException e )
> {
> throw new ArchiveCreationException( "Error retrieving
> module-set for project: " + project.getId()
> + ": " + e.getMessage(), e );
> }
> }
> {code}
> If on the other hand (for working around the issue) one sets
> includeSubModules=false in the assembly definition (just uncomment in the
> "assembly-share" project assembly definition in the submitted example), then
> the reactor projects are used as per the top aggregator and everything goes
> well, except for the fact that another warning shows up saying that
> includeSubModules=false and useAllReactorProjects=true are incompatible and
> will be ignored (this combination is not ignored but the warning does make
> sense, though!)
> This is related to the fact that in the child-aggregator project and modules,
> there is no dependency between the child-type1 project and the
> child-aggregator, which means the Reactor will order the builds as
> child-type1, child-assembler, child-aggregator
> but the code actually selects child-type1 as the "project" to determine
> modules from.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
