Details
-
Bug
-
Status: Closed
-
Minor
-
Resolution: Cannot Reproduce
-
2.2-beta-2
-
None
-
None
-
Mac OS X 10.5.5, Java 1.5.0_16, Maven 2.0.9
Description
When interpreting assembly descriptors, it looks like Maven is resolving fileSet directories relative to where the build was started, rather than relative to the project or module the descriptor is defined in. This might cause problems in multi-module builds where a file exists in the same directory listed in the descriptor, but in an ancestor module. The attached file has a small project that illustrates this. This project has one sub-module, in which an assembly descriptor is defined. It declares a fileSet, using the directory tag, that points to src/main/shell. There is a shell file here (b.sh) that is to be included in the assembly. There is a also a src/main/shell directory in the parent project as well, containing a file (a.sh) that does not exist in the shell directory of the sub-module. The assembly plugin is attached to the package phase. When the sub-module is built from its own directory, everything works as expected. However, if it is built from the parent directory as part of a reactor build, Maven complains that it cannot find a.sh in the sub-module's src/main/shell directory.
This looks like it only happens if the assembly specifies that the fileSet be filtered.
There is an easy workaround; instead of setting the directory as src/main/shell, use ${basedir}/src/main/shell in the assembly descriptor. I discovered this behavior when I was transitioning one of my projects from a single project to a multi-module project, and I left some files behind in the new parent project. I'm going to get rid of those eventually, and I realize this is probably a pathological structure, but this behavior is unexpected and may impact other, less pathological projects.