You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@buildr.apache.org by Alex Boisvert <al...@gmail.com> on 2009/12/23 20:38:56 UTC
include :as is lazy?
On Tue, Dec 22, 2009 at 12:22 PM, Peter Schröder <ps...@blau.de> wrote:
> hi,
>
> i have some problem understanding the documentation of packaging:
>
> snip---
>
> You can also use :as=>'.' to include all files from the given directory.
> For example:
>
> package(:zip).include 'target/docs/*'
> package(:zip).include 'target/docs', :as=>'.'
>
> These two are almost identical. They both include all the files from the
> target/docs directory, but not the directory itself. But they operate
> differently. The first line expands to include all the files in target/docs.
> If you don’t already have files in target/docs, well, then it won’t do
> anything interesting. Your ZIP will come up empty. The second file includes
> the directory itself, but strips the path during inclusion. You can define
> it now, create these files later, and then ZIP them all up.
>
> ---snip
>
> i couldnt figure out where there is a difference between the two
> definitions.
>
> this is what i thought should create zips with different content:
>
> # this selects all files currently available in the include-directory (and
> sub-directory)
> package(:file=>_(:target,
> 'direct_include.zip')).include('target/resources/*')
> # this selects the same but not at definition-time but at execution-time
> package(:file=>_(:target, 'lazy_include.zip')).include('target/resources',
> :as=>'.')
>
> # extend the build-task to write some additional file
> build do
> write('target/resources/additional.txt', 'content')
> end
>
> feel free to bash on my naive approach ;-)
>
> happy christmas to everyone
Looks like a bug to me. I can easily fix it but... I'm pretty worried that
it would break builds out there that inadvertently depend on the current
behavior.
Moreover, I think the default should be lazy. Packaging things from
:targetis pretty common. Problem is, referencing anything from
:target in a buildfile that depends on strict (as opposed to lazy) packaging
behavior is a bit dangerous because *the clean task runs after the project
is defined.* So either you assume that people always do a separate buildr
clean before doing buildr package, or you should seriously reconsider using
strict behavior and fishing things out of :target. Otherwise, people will
get surprises in their packages.
I would rather have people explicitly write,
package(:file=>_(:target, 'direct_include.zip')).include
FileList[_('target/resources/*')]
to get the strict behavior.
Any other opinions on this? Am I the only one to regularly use buildr clean
package?
alex
PS: By the way, you have paths in your example that are not properly
converted to absolute locations with _()... tread carefully!
PPS: But worse -- like, way worse -- we made the same mistake in our
documentation!! Eeeeck! (I'll fix this immediately)
Re: include :as is lazy?
Posted by Alex Boisvert <al...@gmail.com>.
On Sat, Dec 26, 2009 at 11:52 AM, Peter Schröder <ps...@blau.de> wrote:
> hi alex,
>
> most of the problems i get around are actually examples from the
> documentation!
>
Understood and I'm very thankful you bring these up. Buggy documentation
is often worse than buggy code.
i (and all the people i am working with) use a 'buildr clean package' call
> for actually creating distributables. i think that everyone using a
> ci-system would take that approach for granted.
>
Yes, that's what I thought.
i usually use the _ aka path_to method for resolving paths (but i remember
> that there were some other problems with this, i will put this into another
> mail if i run into them again).
>
> you can have a look at the actual example here:
> http://github.com/phoet/buildr-examples/blob/master/packaging/include_exclude/buildfile#L41
>
Yep, so unless anybody objects, I'm going to fix the documentation and
declare that:
package(:file=>_(:target, 'direct_include.zip')).
include('target/resources/*')
is just as lazy as:
package(:file=>_(:target, 'lazy_include.zip')).
include('target/resources', :as=>'.')
for the reason mentioned in my last email.
alex
AW: include :as is lazy?
Posted by Peter Schröder <ps...@blau.de>.
hi alex,
most of the problems i get around are actually examples from the documentation!
i (and all the people i am working with) use a 'buildr clean package' call for actually creating distributables. i think that everyone using a ci-system would take that approach for granted.
or did you mean a 'buildr clean' 'buildr package' (which i would think is a no-go)?!
i usually use the _ aka path_to method for resolving paths (but i remember that there were some other problems with this, i will put this into another mail if i run into them again).
you can have a look at the actual example here: http://github.com/phoet/buildr-examples/blob/master/packaging/include_exclude/buildfile#L41
kind regards,
peter
________________________________________
Von: Alex Boisvert [alex.boisvert@gmail.com]
Gesendet: Mittwoch, 23. Dezember 2009 20:38
An: users@buildr.apache.org
Betreff: include :as is lazy?
On Tue, Dec 22, 2009 at 12:22 PM, Peter Schröder <ps...@blau.de> wrote:
> hi,
>
> i have some problem understanding the documentation of packaging:
>
> snip---
>
> You can also use :as=>'.' to include all files from the given directory.
> For example:
>
> package(:zip).include 'target/docs/*'
> package(:zip).include 'target/docs', :as=>'.'
>
> These two are almost identical. They both include all the files from the
> target/docs directory, but not the directory itself. But they operate
> differently. The first line expands to include all the files in target/docs.
> If you don’t already have files in target/docs, well, then it won’t do
> anything interesting. Your ZIP will come up empty. The second file includes
> the directory itself, but strips the path during inclusion. You can define
> it now, create these files later, and then ZIP them all up.
>
> ---snip
>
> i couldnt figure out where there is a difference between the two
> definitions.
>
> this is what i thought should create zips with different content:
>
> # this selects all files currently available in the include-directory (and
> sub-directory)
> package(:file=>_(:target,
> 'direct_include.zip')).include('target/resources/*')
> # this selects the same but not at definition-time but at execution-time
> package(:file=>_(:target, 'lazy_include.zip')).include('target/resources',
> :as=>'.')
>
> # extend the build-task to write some additional file
> build do
> write('target/resources/additional.txt', 'content')
> end
>
> feel free to bash on my naive approach ;-)
>
> happy christmas to everyone
Looks like a bug to me. I can easily fix it but... I'm pretty worried that
it would break builds out there that inadvertently depend on the current
behavior.
Moreover, I think the default should be lazy. Packaging things from
:targetis pretty common. Problem is, referencing anything from
:target in a buildfile that depends on strict (as opposed to lazy) packaging
behavior is a bit dangerous because *the clean task runs after the project
is defined.* So either you assume that people always do a separate buildr
clean before doing buildr package, or you should seriously reconsider using
strict behavior and fishing things out of :target. Otherwise, people will
get surprises in their packages.
I would rather have people explicitly write,
package(:file=>_(:target, 'direct_include.zip')).include
FileList[_('target/resources/*')]
to get the strict behavior.
Any other opinions on this? Am I the only one to regularly use buildr clean
package?
alex
PS: By the way, you have paths in your example that are not properly
converted to absolute locations with _()... tread carefully!
PPS: But worse -- like, way worse -- we made the same mistake in our
documentation!! Eeeeck! (I'll fix this immediately)