You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Dennis Lundberg (JIRA)" <ji...@codehaus.org> on 2012/10/25 08:28:13 UTC
[jira] (MASSEMBLY-600) ModuleSets incorrectly detected with
useAllReactorProjects while aggregating modules with parents differing from
the aggregator
[ 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