[
https://jira.codehaus.org/browse/MASSEMBLY-600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MASSEMBLY-600:
--------------------------------------
Component/s: moduleSet
> 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
> Components: moduleSet
> 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