You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Christopher Maier (JIRA)" <ji...@codehaus.org> on 2008/11/19 20:51:42 UTC

[jira] Created: (MASSEMBLY-365) Filtered directory filesets try to include files from ancestor projects in a multi-module build

Filtered directory filesets try to include files from ancestor projects in a multi-module build
-----------------------------------------------------------------------------------------------

                 Key: MASSEMBLY-365
                 URL: http://jira.codehaus.org/browse/MASSEMBLY-365
             Project: Maven 2.x Assembly Plugin
          Issue Type: Bug
    Affects Versions: 2.2-beta-2
         Environment: Mac OS X 10.5.5, Java 1.5.0_16, Maven 2.0.9
            Reporter: Christopher Maier
            Priority: Minor
         Attachments: assembly-bug.tar.bz

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.

-- 
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] (MASSEMBLY-365) Filtered directory filesets try to include files from ancestor projects in a multi-module build

Posted by "Dennis Lundberg (JIRA)" <ji...@codehaus.org>.
     [ https://jira.codehaus.org/browse/MASSEMBLY-365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dennis Lundberg updated MASSEMBLY-365:
--------------------------------------

    Component/s: filtering
    
> Filtered directory filesets try to include files from ancestor projects in a multi-module build
> -----------------------------------------------------------------------------------------------
>
>                 Key: MASSEMBLY-365
>                 URL: https://jira.codehaus.org/browse/MASSEMBLY-365
>             Project: Maven 2.x Assembly Plugin
>          Issue Type: Bug
>          Components: filtering
>    Affects Versions: 2.2-beta-2
>         Environment: Mac OS X 10.5.5, Java 1.5.0_16, Maven 2.0.9
>            Reporter: Christopher Maier
>            Priority: Minor
>         Attachments: assembly-bug.tar.bz
>
>
> 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.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira