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.boisv...@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 <p...@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)
