On Apr 16, 2009, at 6:19 PM, Steve Appling wrote:
Hans Dockter wrote:
On Apr 16, 2009, at 5:19 PM, Steve Appling wrote:
Hans Dockter wrote:
This makes sense to me. I have renamed the testCompile task to
compileTests. I have also renamed the resources task to
processResources (the same for testResources).
While you are renaming things :)
I find that we use tasks of type Resources often for copying in
other tasks. While processResources is a fine name for the task,
it seems that org.gradle.api.tasks.Resources should perhaps be
renamed to Copy.
This is a good point. I will do this. Speaking about resources and
copying. At one point we would like to get rid of our internal Ant
based copy/resources handling. That would open up the way for a
more powerful API. The problem with the Ant tasks is that they are
mostly a one way street and don't give you any information. For
example it would be nice to know whether a copy operation has
actually copied something (in the case you want to copy only newer
files). Such information can speed up a development build, as you
then can decide not to trigger certain tasks.
It's interesting that you mentioned that. I have implemented my own
'Sync' type of task that we actually use for copying instead of the
current Resources type. It can 'sync' source and destination
directories so that it will remove a target file if the source file
is removed (without having to do a clean). I also have support for
regular expression based file name mapping (like the Ant
regexpmapper). It's also about twice as fast as the current
'Resources' type of task when all files are up to date and nothing
needs to be copied. Next on my list is to support content filtering
during the copy.
I would be glad to contribute this if you are interested.
We are very interested. Our goal is to get rid of any internal
dependency on Ant rather sooner than later. Now that common-compress
is no longer dormant and promoted to commons proper this seems to be
within reach.
- Hans
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
