On 12/01/10 10:01 AM, phil swenson wrote:
I want to write a task(or plugin maybe?) for gradle that searches a
bunch of jars for a class name pattern. For example, I have a ton of
classes and don't know what jar they are in. So I want to write a
gradle task that finds them.
Anyway, this kind of code will pollute the build.gradle file. So what
do most people do to keep their gradle files from becoming monstrous?
There's a couple of options, which work for both custom tasks and plugins.
The simplest option is to add the source for the build classes in the
buildSrc project. This project is built before the build scripts are
compiled and executed, and its classes are available in the build script
class path. To use this, you drop the source in the
buildSrc/src/main/groovy directory and they will automatically be
compiled and included.
Another option is to use a separate build for the build classes, which
compiles them into a jar, and deploys the jar to a repository somewhere.
The build script can then declare a dependency on that jar, and it will
be included in the class path for the build script.
There are some pretty basic examples of these in the user guide:
http://gradle.org/0.8/docs/userguide/organizing_build_logic.html
There will be a third option in the Gradle 0.9 release, where you can
place your build classes in an external script, and include it from the
build script. Gradle will take care of compiling and caching the script,
and making the classes from it available in the build script. And in the
Gradle 0.10 time frame, we will make this all a bit more flexible by
letting you mix and match these different options more easily.
--
Adam Murdoch
Gradle Developer
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
