On 4/04/10 7:52 PM, Russel Winder wrote:
On Sun, 2010-04-04 at 08:05 +1000, Adam Murdoch wrote:
On 4/04/10 2:43 AM, Russel Winder wrote:
[ . . . ]
task binTgz ( type : Tar , dependsOn : 'jar' , description : 'Build the
distribution tarball.' ) {
baseName = artifact
classifier = mavenNameExtension + '-' + groovyVersion
compression = Compression.GZIP
into ( gantPrefix ) { from binCopySpec }
This should be '{ with binCopySpec }'. The 'from' was renamed to 'with'
when you're adding another CopySpec.
Interesting. I had another tarball builder:
task standaloneBinTgz ( type : Tar , dependsOn :
projectNameForStandalone + ':jar' , description : 'Create a tarball of the
standalone distribution.' ) {
baseName = artifact
version = gantVersion
compression = Compression.GZIP
destinationDir = buildDir
into ( gantPrefix ) { from standaloneCopySpec }
}
which appeared to work fine -- at least the tarball was being created
and appeared to have the right content.
s/from/with/ in all the uses of a copySpec does appear to have fixed the
problem of tarballs and zips not being produced. So we have a
significant step forward :-) Though the tarball generated by the above
stadalonBinTgz is the same as the one using with. I guess this will
just have to remain a mystery.
Perhaps from() should delegate to with() when it is passed a CopySpec.
Or perhaps copy() should throw an exception when passed a CopySpec, as
it's almost certainly not what you want to do.
I am not following your last point. I thought copySpecs were ideal for
use with copy -- the name is sort of indicative that this is true, is
this not, in fact, the case?
Oops, typo. Should be: Perhaps from() should throw an exception when
passed a CopySpec.
Right now, if you pass from() a CopySpec, Gradle calls toString() on it,
and looks for a file with that name under the project directory. Which
is pretty useless behaviour. So from() could, when passed a CopySpec,
pass it on to with(), or could throw an exception telling you to use
with() instead.
Unfortunately, we don't have a 'breaking changes' page for our 'breaking
changes' page to let people know about these sorts of changes. Not sure
how we can deal with this sort of thing, from a process point of view.
There are occasions when the rapidity of change on a day to day basis is
overwhelming. Of course this is the bleeding edge, so there is no
expectation of stability. However, there are sometimes so many breaking
changes between one snapshot release and the next that it is hard to
keep up with the changes to the changes to the change to the . . .
I'm not sure what we can do. I think a lot of the changes are to new
things, which haven't been included in a release. The problem is these
new things usually need a bit of 'soak time' before you get a feel for
what works and what doesn't work, and need some revision before the
release. The other breaking changes, to things which have been included
in a release, will ideally start to drop off as we get closer to a 1.0
release. Certainly after 1.0, we'll put more effort into backward
compatibility.
--
Adam Murdoch
Gradle Developer
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
