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

2006-08-04 Thread LECAN Damien 
Hello,

This problem has already been reported :
http://jira.codehaus.org/browse/MASSEMBLY-117

Vote for it :)

 Unfortunately this always fails into an exception: pom:pom1.1 does not
 have an artifact with a file. Please ensure the package phase (...)
You can avoid this problem by excluding theses modules with 'pom' packaging.

 Thanks in advance if you have any workaround.
For the recursion problem, I made my own assembly plugin release (with the 
patch provided in the bug report).

Damien

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Assembly including binaries: Bug on a n depth hierarchy

2006-08-03 Thread Alexis Midon 

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
   idcollect-alljars/id
   formats
   formatdir/format
   /formats
includeBaseDirectoryfalse/includeBaseDirectory
   moduleSets
   moduleSet
   binaries
   unpackfalse/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

2006-08-03 Thread 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
idcollect-alljars/id
formats
formatdir/format
/formats
 includeBaseDirectoryfalse/includeBaseDirectory
moduleSets
moduleSet
binaries
unpackfalse/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