José Pedro Pereira created MASSEMBLY-600:
--------------------------------------------
Summary: 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.3, 2.2.2, 2.2
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:
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.
--
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
