Adam Murdoch wrote:
I'm still not sure about adding Project.copy(). It feels out of place
there. Maybe a better place for it would be on File and/or
FileCollection.
I'm not really sure what to do about this either. There are a lot of
subclasses of FileCollection (including Configuration which already
has a copy). I think this would be confusing here.
FileCollection simply represents the things you can do to a collection
of files. Being able to copy them somewhere makes perfect sense. We
might have, for example, something like:
configurations.compile.copy(into: 'build/dists/exploded/libs')
configurations.compile.copy { into: 'somedir'; exclude {
it.isDirectory() }; rename { ... } }
files('a', 'b').copy(into: 'build/libs')
new FileSet(dir: 'src', includes: ['**/*.java']).copy(into: 'build/src')
And for file:
file('some.xml').copy(into: 'build/somedir')
file('some.xml').copy { into 'build/somedir'; replaceTokens(...) }
This could then grow into a decent file manipulation DSL (on top of the
goodness that Groovy already provides)
Adding Project.copy() has a couple of problems, I think:
- Project gets bigger. We want to be careful not to keep adding stuff to
Project, just because it's there.
- Copying doesn't really have anything to do with projects. It belongs
somewhere better related to file operations. It also belongs somewhere
that is usable when you don't have a project, and outside the build script.
Adding copy operations to FileCollection and File is one way to address
these problems.
I don't like it in Project either. I think that this fits naturally with
FileCollection as you described. Thanks for the examples. I was originally
thinking you were describing merging in the CopySpec into the FileSet in some
way, but many of items (like into) didn't make sense there. I don't know why it
wasn't obvious to me to break it up like this.
Do you think that it is useful to be able to access other Tasks in a
similar way?
I think it would be useful to be able to use the operations that some
tasks also happen to use. I don't think it's a good idea to use them as
tasks.
Should you be able to use tasks.copy { } or tasks.zip { }?
No. But you should be able to easily write code which can copy, move,
zip, unzip, tar, etc files. That code could be in a build script, a
plugin, a custom task, a library class, or internal to Gradle. It could
be Groovy or Java.
Again, adding these operations to FileCollection and File solves this
problem. Adding them to Project does not.
I can write a little more about the copy task in the userguide if you
think it is needed.
I am on vacation until Tuesday. I don't know what the current release schedule
is, but I can do something quick then.
Do you know where it should go?
What do you think about having a reference section for each of the types of
Tasks?
That would be good.
Adam
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
--
Steve Appling
Automated Logic Research Team
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
