On 21/08/10 6:46 AM, Eric Berry wrote:
I'm making some progress on this. Initially, I think my plugin is
going to have these tasks:
build
clean
cleanAll
What would be the difference between clean and cleanAll?
You might think about applying the JavaBasePlugin from your plugin. It
will add these tasks like clean, build, and so on for you.
combineJavascript
compileJavascript
compileTestJavascript
distJavascript
What would this task do?
docJavascript
filterJavascript
minifyJavascript
testJavascript
You might think about adding a dependency from 'check' to 'testJavascript'
I have some questions though. First, my 'compileJavascript' task is
probably just going to be a meta-task which just depends on, or calls
the 'combineJavascript', and 'filterJavascript' tasks. I've created
the latter 2 to extend SourceTask, but I'm not sure how to hook them
up with a JavascriptPluginConvention object. Can someone please
explain to me how I can make use of a convention, and have it set the
source, includes, excludes, etc.. in a SourceTask? Also, if I have the
compile task simply depends on, or call the combine and filter tasks,
can I have 1 configuration for those tasks which or should I have
individual ones for each? Eg. it doesn't make sense to have a
"filterSourceDir", and "combineSourceDir". I'd rather just have the
user supply/set 1 sourceDir and just use that in both tasks. I'm
thinking this should be part of the convention, but again, not sure
how to hook the convention up with extended tasks.
There's some information about this in the user guide:
http://gradle.org/0.9-rc-1/docs/userguide/custom_plugins.html#N148A7
Also, have a look at this mail thread for some more info:
http://markmail.org/message/zdyafo5qpq4llkl2
Would I do something kind of like:
[code lang=groovy]
class JavascriptPlugin implements Plugin<Project> {
void apply(Project project) {
...
project.task('combineJavascript', type: Source) << {
super.source = project.convention.plugins.javascript.srcDir
super.excludes =
project.convention.plugins.javascript.srcExcludes
super.execute()
}
...
}
}
[/code]
Also, if I want the doc, minify, and test tasks to execute some
external process what's the appropriate way to handle this?
You might use the Exec or JavaExec tasks.
Is it possible for plugins to define dependencies on external jars?
Yes. For example, the Groovy plugin does this for Groovy.
Eg. There is a Google "Closure Compiler" jar file which I could
download then use via command line on the user's sources.
Or is it better to do a check for the existence of the libraries on
the filesystem and print an error to users if those libraries are not
installed?
Personally, I think it's better to download them.
Lastly, and this is more from a usability standpoint, I noticed that
when I have a task that is a dependency of another task, the first
task doesn't show up with I do a 'gradle -t'. Is there a way to see
ALL available tasks for a build script?
The user guide has some information about this:
http://gradle.org/0.9-rc-1/docs/userguide/tutorial_gradle_command_line.html#sec:obtaining_information_about_your_build
Basically, if you want a task to show up in the output of gradle -t, you
should assign it to a group. And, if you want to see all task for a
project, you can run gradle -t --all
--
Adam Murdoch
Gradle Developer
http://www.gradle.org
CTO, Gradle Inc. - Gradle Training, Support, Consulting
http://www.gradle.biz
