Re: Assembly including binaries: Bug on a n depth hierarchy

[Alexis Midon]

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 <[EMAIL PROTECTED]> 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