maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From José Pedro Pereira (JIRA) <>
Subject [jira] (MASSEMBLY-600) ModuleSets incorrectly detected with useAllReactorProjects while aggregating modules with parents differing from the aggregator
Date Wed, 15 Feb 2012 23:36:02 GMT
José Pedro Pereira created MASSEMBLY-600:

             Summary: ModuleSets incorrectly detected with useAllReactorProjects while aggregating
modules with parents differing from the aggregator
                 Key: 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

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
 |___(module)___ shared-assembly-defs (type=jar)
                                                |____________ 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

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:



public static Set<MavenProject> getModuleProjects( final ModuleSet moduleSet,
                                                       final AssemblerConfigurationSource
                                                       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 )
                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:!default.jspa
For more information on JIRA, see:


View raw message