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 : collect-alljars dir false false 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 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
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
:
collect-alljars
dir
false
false
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 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
unsucribe
issues MASSEMBLY-120
Hi all I'd like to know if this issue has been submitted: http://jira.codehaus.org/browse/MASSEMBLY-120 IMHO, it seems it hasn't been. I checkout the source code recently, but this feature seems to be missing. Thanks for your help. Alexis
[jira] Created: (MASSEMBLY-131) Missing 'return' statement in AbstractAssemblyMojo#isProjectModule()
Missing 'return' statement in AbstractAssemblyMojo#isProjectModule() Key: MASSEMBLY-131 URL: http://jira.codehaus.org/browse/MASSEMBLY-131 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.1 Reporter: Alexis Midon Attachments: AbstractAssemblyMojo.java A 'return' statement is missing line 716, in AbstractAssemblyMojo#isProjectModule() Check the "else if ( recurse )" close. Path is delimited by : // PATCH BEGIN // PATCH END -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MASSEMBLY-133) Assembly including binaries: Bug on a n depth hierarchy
Assembly including binaries: Bug on a n depth hierarchy --- Key: MASSEMBLY-133 URL: http://jira.codehaus.org/browse/MASSEMBLY-133 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.1 Environment: Maven 2.0.4 Reporter: Alexis Midon Priority: Critical Attachments: AbstractAssemblyMojo.java Considering 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 : collect-alljars dir false false 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 be included in the module list but jar:pom2.0 and jar:pom2.1 should be too! 2. the tag must not throw an exception if there is no file, distonction on packaging type sounds necessary 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? The patch is delimited by // PATCH BEGIN/END, modif on lines 470 and 514. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MASSEMBLY-131) Missing 'return' statement in AbstractAssemblyMojo#isProjectModule()
[ http://jira.codehaus.org/browse/MASSEMBLY-131?page=all ] Alexis Midon closed MASSEMBLY-131. -- Resolution: Duplicate duplicate of issue 117 > Missing 'return' statement in AbstractAssemblyMojo#isProjectModule() > > > Key: MASSEMBLY-131 > URL: http://jira.codehaus.org/browse/MASSEMBLY-131 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Alexis Midon > Attachments: AbstractAssemblyMojo.java > > > A 'return' statement is missing line 716, in > AbstractAssemblyMojo#isProjectModule() > Check the "else if ( recurse )" close. > Path is delimited by : > // PATCH BEGIN > // PATCH END -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MASSEMBLY-133) Assembly including binaries: Bug on a n depth hierarchy
[ http://jira.codehaus.org/browse/MASSEMBLY-133?page=all ] Alexis Midon closed MASSEMBLY-133. -- Resolution: Duplicate duplicate of issue 117 > Assembly including binaries: Bug on a n depth hierarchy > --- > > Key: MASSEMBLY-133 > URL: http://jira.codehaus.org/browse/MASSEMBLY-133 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.1 > Environment: Maven 2.0.4 >Reporter: Alexis Midon >Priority: Critical > Attachments: AbstractAssemblyMojo.java > > > Considering 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 : > > collect-alljars > > dir > > false > > > > false > > > > > 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 be included in the module list but > jar:pom2.0 and jar:pom2.1 should be too! >2. the tag must not throw an exception if there is no file, > distonction on packaging type sounds necessary > 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? > The patch is delimited by // PATCH BEGIN/END, modif on lines 470 and 514. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-120) ModuleSet/Binaries include/exclude not implemented
[ http://jira.codehaus.org/browse/MASSEMBLY-120?page=comments#action_73110 ] Alexis Midon commented on MASSEMBLY-120: Hi, is the fix submitted? > ModuleSet/Binaries include/exclude not implemented > -- > > Key: MASSEMBLY-120 > URL: http://jira.codehaus.org/browse/MASSEMBLY-120 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.1 > Environment: linux (fedora core 5) / maven 2.0.4 / java 1.5 >Reporter: Simon Goodall > Assigned To: John Casey > > The binaries section of moduleSet has an include / exclude section defined, > but it is not implemented. Currently a module can only include all or none of > its dependencies (through the includeDependencies tag). There is no selective > inclusion/exclusion of dependencies. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MDEP-65) Copy dependencies in a Maven repository like layout
Copy dependencies in a Maven repository like layout
---
Key: MDEP-65
URL: http://jira.codehaus.org/browse/MDEP-65
Project: Maven 2.x Dependency Plugin
Issue Type: New Feature
Affects Versions: 2.0-alpha-2, 2.0
Reporter: Alexis Midon
Assigned To: Brian Fox
Attachments: repository-layout.patch
I use the dependency plugin in my Maven project at work.
But we need a tiny feature not yet implemented by your plugin.
Actually we would like to copy some dependencies in a repository like layout.
This exactly what your plugin does except for the repository part.
_example:_ I'd like to move dependencies in something like
{{outputDirectory/junit/junit/3.8.1/junit-3.8.1.jar}} and so on
To help you, I implemented this feature in the maven-dependency-plugin trunk
(as of revision 510010) and the patch is in attachment.
Here are details of the development:
- add a new optional boolean property in
org.apache.maven.plugin.dependency.AbstractFromDependenciesMojo :
useRepositoryLayout
- add a new parameter to DependencyUtil.getFormattedOutputDirectory(...)
- update all calls to this method
- update unit test and add specific tests for this new parameter
_Example POM:_
{code:xml}
org.apache.maven.plugins
maven-dependency-plugin
copy-dependencies
package
copy-dependencies
${project.build.directory}/alternateLocation
true
{code}
I tried to create a new issue in jira but the url failed.
I hope you will find this feature attractive, and I will be glad to answer any
of your request about it.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
