On 3/07/10 5:36 AM, John Murph wrote:
In playing with the Gradle wrapper. What we have are public APIs that
we deliver so users can extend the product. Along with the jars to
compile against we include the javadocs and some samples that use the
APIs. I want to stop shipping Ant build.xmls and start shipping
build.gradles. So, I thought I would ship gradlew along with this so
that the user can easily generate IDEA or Eclipse projects for the
samples and my life also becomes simpler (plus I can't stand using Ant
now that I've used Gradle so much).
My problem is that the "Wrapper" task assumes that everything is
relative to the project directory. I don't think this is what I
want. I think I want to copy my samples to buildDir/<something> and
generate the wrapper into that place. Then I want to run the samples
using the generated gradlew and make sure that they can build and
their tests pass. Then I want to put the samples and gradlew into a
zip for distribution. The first part of this was getting the wrapper
into the correct place. I set "scriptDestinationPath" to go to my
build directory (using weird relative path stuff) but the wrapper.jar
and wrapper.properties were still put under my projectDir. It would
be nice if the task would:
1) Recognize if I give it a "scriptDestinationPath" that is an
absolute path and just use that.
2) Put everything relative to the parentFile of the
"scriptDestinationPath".
Am I insane? OK, don't answer that. Is this idea insane?
I think it's a good idea. Could you add a JIRA issue?
In general, we want every File property (eg
wrapper.scriptDestinationPath, and there's heaps of others) to be
settable using anything which Project.file() can accept: File, relative
path, absolute path, URL, and so on.
Also, I think the Wrapper task itself could do with some simplification.
There are too many properties there to specify basically 2 things: where
should the script go? and what should it download?
--
Adam Murdoch
Gradle Developer
http://www.gradle.org
CTO, Gradle Inc. - Gradle Training, Support, Consulting
http://www.gradle.biz
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
