You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by Alexis Midon <al...@gmail.com> on 2006/08/03 17:28:45 UTC
Assembly including binaries: Bug on a n depth hierarchy
Hi all,
I have the following complex but common pom hierarchy (sample) :
The syntax is packaging:pom:level.#
pom:pom0.0
/\
/ \
/ \
/ \
/ \
jar:pom1.0 pom:pom1.1
/\
/ \
/ \
/ \
/ \
jar:pom2.0 jar:pom2.1
I'd like to use the assembly plugin to gather all the output jars in a
single directory.
(So every child/target/artifact.jar must copy to root/target/assembly/...)
To do so I execute the assemby:assembly goal with the following descriptor :
<assembly>
<id>collect-alljars</id>
<formats>
<format>dir</format>
</formats>
<includeBaseDirectory>false</includeBaseDirectory>
<moduleSets>
<moduleSet>
<binaries>
<unpack>false</unpack>
</binaries>
</moduleSet>
</moduleSets>
</assembly>
Unfortunately this always fails into an exception: "pom:pom1.1 does not have
an artifact with a file. Please ensure the package phase (...)"
This use case highlights 2 problems I think:
1. the assembly plugin does not support n depth hierarchy
Actually pom:pom1.1 should not be included in the module list while
jar:pom2.0 and jar:pom2.1 should.
2. the <binaries/> tag must not throw an exception if there is no
file, I think
To understand what's going on with bug #1, I decided to debug the plugin.
The problem occurs in AbstractAssemblyMojo.processModules (...) line 471
The getModulesFromReactor() method is invoked but with recurse set to false!
As a result when jar:pom2.0 is tested, the isProjectModule() method returns
false, which is not correct (in our case).
May be 'recurse' could be a plugin parameter?
I don't know if everybody will call this a bug, nor if this list is the
right place to report but I hope it will help.
Thanks in advance if you have any workaround.
Alexis
Re: Assembly including binaries: Bug on a n depth hierarchy
Posted by Alexis Midon <al...@gmail.com>.
I forgot to add that there is a real bug in
AbstractAssemblyMojo.isProjectModule() method.
A return statement is missing line716
private boolean isProjectModule( String parentId, MavenProject
reactorProject, boolean recurse )
{
MavenProject parent = reactorProject.getParent();
if ( parent != null )
{
if ( parent.getId().equals( parentId ) )
{
return true;
}
else if ( recurse )
{
return isProjectModule( parentId, parent, true );
}
}
return false;
}
On 8/3/06, Alexis Midon <al...@gmail.com> wrote:
>
>
> Hi all,
>
> I have the following complex but common pom hierarchy (sample) :
> The syntax is packaging:pom:level.#
>
> pom:pom0.0
> /\
> / \
> / \
> / \
> / \
> jar:pom1.0 pom:pom1.1
> /\
> / \
> / \
> / \
> / \
> jar:pom2.0 jar:pom2.1
>
>
> I'd like to use the assembly plugin to gather all the output jars in a
> single directory.
> (So every child/target/artifact.jar must copy to root/target/assembly/...)
>
>
> To do so I execute the assemby:assembly goal with the following descriptor
> :
>
> <assembly>
> <id>collect-alljars</id>
> <formats>
> <format>dir</format>
> </formats>
> <includeBaseDirectory>false</includeBaseDirectory>
> <moduleSets>
> <moduleSet>
> <binaries>
> <unpack>false</unpack>
> </binaries>
> </moduleSet>
> </moduleSets>
> </assembly>
>
> Unfortunately this always fails into an exception: "pom:pom1.1 does not
> have an artifact with a file. Please ensure the package phase (...)"
>
> This use case highlights 2 problems I think:
>
> 1. the assembly plugin does not support n depth hierarchy
> Actually pom:pom1.1 should not be included in the module list while
> jar:pom2.0 and jar:pom2.1 should.
> 2. the <binaries/> tag must not throw an exception if there is no
> file, I think
>
>
> To understand what's going on with bug #1, I decided to debug the plugin.
> The problem occurs in AbstractAssemblyMojo.processModules (...) line 471
> The getModulesFromReactor() method is invoked but with recurse set to
> false!
>
> As a result when jar:pom2.0 is tested, the isProjectModule() method
> returns false, which is not correct (in our case).
> May be 'recurse' could be a plugin parameter?
>
> I don't know if everybody will call this a bug, nor if this list is the
> right place to report but I hope it will help.
>
> Thanks in advance if you have any workaround.
>
> Alexis
>
Re: Assembly including binaries: Bug on a n depth hierarchy
Posted by Alexis Midon <al...@gmail.com>.
I forgot to add that there is a real bug in
AbstractAssemblyMojo.isProjectModule() method.
A return statement is missing line716
private boolean isProjectModule( String parentId, MavenProject
reactorProject, boolean recurse )
{
MavenProject parent = reactorProject.getParent();
if ( parent != null )
{
if ( parent.getId().equals( parentId ) )
{
return true;
}
else if ( recurse )
{
return isProjectModule( parentId, parent, true );
}
}
return false;
}
On 8/3/06, Alexis Midon <al...@gmail.com> wrote:
>
>
> Hi all,
>
> I have the following complex but common pom hierarchy (sample) :
> The syntax is packaging:pom:level.#
>
> pom:pom0.0
> /\
> / \
> / \
> / \
> / \
> jar:pom1.0 pom:pom1.1
> /\
> / \
> / \
> / \
> / \
> jar:pom2.0 jar:pom2.1
>
>
> I'd like to use the assembly plugin to gather all the output jars in a
> single directory.
> (So every child/target/artifact.jar must copy to root/target/assembly/...)
>
>
> To do so I execute the assemby:assembly goal with the following descriptor
> :
>
> <assembly>
> <id>collect-alljars</id>
> <formats>
> <format>dir</format>
> </formats>
> <includeBaseDirectory>false</includeBaseDirectory>
> <moduleSets>
> <moduleSet>
> <binaries>
> <unpack>false</unpack>
> </binaries>
> </moduleSet>
> </moduleSets>
> </assembly>
>
> Unfortunately this always fails into an exception: "pom:pom1.1 does not
> have an artifact with a file. Please ensure the package phase (...)"
>
> This use case highlights 2 problems I think:
>
> 1. the assembly plugin does not support n depth hierarchy
> Actually pom:pom1.1 should not be included in the module list while
> jar:pom2.0 and jar:pom2.1 should.
> 2. the <binaries/> tag must not throw an exception if there is no
> file, I think
>
>
> To understand what's going on with bug #1, I decided to debug the plugin.
> The problem occurs in AbstractAssemblyMojo.processModules (...) line 471
> The getModulesFromReactor() method is invoked but with recurse set to
> false!
>
> As a result when jar:pom2.0 is tested, the isProjectModule() method
> returns false, which is not correct (in our case).
> May be 'recurse' could be a plugin parameter?
>
> I don't know if everybody will call this a bug, nor if this list is the
> right place to report but I hope it will help.
>
> Thanks in advance if you have any workaround.
>
> Alexis
>