maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexis Midon" <alexismi...@gmail.com>
Subject Re: Assembly including binaries: Bug on a n depth hierarchy
Date Thu, 03 Aug 2006 16:21:00 GMT
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 <alexismidon@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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message