[jira] [Resolved] (BUILDR-565) resources are not included in the war if defined after package call

["Antoine Toulme (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/BUILDR-565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Toulme resolved BUILDR-565.
-----------------------------------
    Resolution: Fixed

[master fa4750b] BUILDR-565: resources are not included in the war if defined after package call Added a paragraph to the website explaining the importance of the order of the instructions when defining a build, providing the example given in the bug.
 Date: Thu May 19 23:21:02 2016 -0700
 2 files changed, 14 insertions(+)

> resources are not included in the war if defined after package call
> -------------------------------------------------------------------
>
>                 Key: BUILDR-565
>                 URL: https://issues.apache.org/jira/browse/BUILDR-565
>             Project: Buildr
>          Issue Type: Bug
>          Components: Packaging
>    Affects Versions: 1.4.4
>            Reporter: Stephen Haberman
>            Assignee: Antoine Toulme
>             Fix For: 1.5
>
>         Attachments: resources-skipped.zip
>
>
> I have the issue done to the order of the buildfile instructions. E.g. this order:
> define 'testwar' do
>   project.version = 1.0
>   package(:war)
>   project.resources.from(_('src/main/java')).exclude('*.java')
> end
> With no existing src/main/resources directory means project.resources is nil when package(:war) is called.
> If the custom resources call (project.resources.from...) is put before the package(:war) command, then resources is no longer nill, and they end up in the war's classes directory just fine.
> This is a boundary case bordering on user error--not having a src/main/resources, and defining my own resources after calling package, but I was under the impression the declarative nature of the package/project.resources lines insinuated order was not important.
> Given I can just reorder the lines, this isn't a big deal, but still filling the bug in case there is a way to make it more user-error proof.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)