Maven 2.x Assembly Plugin

ModuleSets incorrectly detected with useAllReactorProjects while aggregating modules with parents differing from the aggregator

Details

  • Type: Bug Bug
  • Status: Open Open
  • Priority: Blocker Blocker
  • Resolution: Unresolved
  • Affects Version/s: 2.2, 2.2.2, 2.3
  • Fix Version/s: None
  • Component/s: moduleSet
  • Labels:
    None
  • Environment:
    Maven 2.2.1
  • Number of attachments :
    1

Description

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.

Activity

There are no comments yet on this issue.

People

  • Assignee:
    Unassigned
    Reporter:
    José Pedro Pereira
Vote (0)
Watch (0)

Dates

  • Created:
    Updated: