[ 
https://issues.apache.org/jira/browse/BUILDR-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12988502#action_12988502
 ] 

Alex Boisvert commented on BUILDR-565:
--------------------------------------

I agree this is undesirable behavior and deviates from the general feeling of 
Buildr being mostly declarative.  I wish there was something we could do to 
easily fix it.  

We could go about making package(...) a lazy construct -- but then we'd get in 
a slippery slide of having to sprinkle laziness across the board and that could 
get pretty messy code-wise.

The general principle in defining projects is that DSL expressions should be 
stated in the same order as their underlying tasks are ordered during the build 
execution.

e.g. "compile.using" should normally precede "test.using", and "test.using" 
should precede "package(:something)", and so on.

Perhaps we could validate and issue warnings if this isn't the case -- but that 
would require separating the superficial DSL constructs from the accessor 
constructs used internally -- also something that would unduly complexify the 
implementation.

So I think my best solution to this issue at this point is to document the 
ordering assumption prominently so that users are more aware of it.


> 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
>         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 is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to