Hi, one comment - the idea is very nice, but let us not forget that all of this can be achieved using ant, so I'd give this task a low priority and concentrate on things that Gradle still lacks.
-- Tomek 2009/10/2 Adam Murdoch <[email protected]>: > > > Hans Dockter wrote: >> >> One of the things I would like to start soon with, is to improve our file >> operations support (Delete, Move, archive handling) >> >> I think Steve's copy stuff is leading the way. > > +1 > >> For each operation we want to have a task as well as a project method as >> well as a spec. So we will have a move/delete/copy/zip/jar/tar >> task/spec/method. Specially for the archive tasks this provides the nice >> feature that specs can be reused for multiple archive operations. For >> example in the Gradle build the different distributions would share a common >> spec (and then have additionally specific specs). The archive specs should >> extend from the copy specs so that copy operations and archive operations >> can share specs. > > I think most (or all?) of the stuff on ZipFileSet and TarFileSet could live > on CopySpec and be supported by both the copy action and archive actions. > For example, prefix (which is almost there in the into property), filemode, > dirmode, etc. > > I would change the 'into' property to be a String path relative to the > destination directory/archive root, and allow into() to optionally take a > configure closure: > > zip { > into 'META-INF' { > from 'src/metaInf' > from '../shared/src/metaInfo' { include '**/staging/**' } > } > } > > And maybe (as, I think, Tom suggested a while back) support a builder style: > > zip { > bin(filemode: '755') { > from 'src/toplevel/scripts' > } > libs { > from configurations.distLibs > } > } > >> Another thing that would be good to have are archives as input(from) >> values for copy/archives operations. That way we can use the copy task to >> unzip/tar/jar. For archives this would provide the current merge >> functionality. >> > > One question is how we distinguish between the case where you want to copy > the archive and the case where you want to copy the contents of the archive. > > One option is to have a method which takes an archive file and returns a > FileTree containing its contents: > > copy { > from 'some.zip' // copies the file > from contentsOf('some.zip') // copies the contents of the file > } > > This allows the expanding stuff to be reused elsewhere: > > contentsOf('some.zip').matching { include 'org/gradle/**' }.visit { println > it.relativePath } > > > There's a few other things which might be useful for our file/archive > handling: > > - Copy and archive actions preserve file permissions (as best they can) > > - Allow an Ant pattern to be specified anywhere that accepts multiple files > as a shorthand: > > files('lib/*.zip') > compileJava.source('src/*/java') > copy(from: 'src/*', into: ...) > > > Adam > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
