On 24/03/10 8:53 AM, phil swenson wrote:
I have been going down the buildSrc approach for building my
build.gradle dependencies. I am starting to think this isn't the
right way.
The reason is that I want to leverage code that is in the product I am
building. Stuff like clean database, starting processes, updating
config files via APIs we built in our product.
So when I try to call classes in my src/test/etc directories,
build.gradle won't build. And if I were to put them in buildSrc, I
would have to duplicate major pieces of build.gradle in
buildSrc/build.gradle as well as if I have any code compilation issue
during development I wouldn't be able to use any tasks in build.gradle
because buildSrc/build.gradle would fail (I think anyway).
So.... I'm thinking of having another gradle file
buildGradleDependencies.gradle in my root. This would be used to
compile all the src files and build an appropriate jar file that build
be referenced in build.gradle like:
buildscript {
repositories {
flatDir(name: 'buildLib', dirs: "./lib")
}
dependencies {
classpath name: 'gradledep'
}
}
This seems clunky to me in that I will have to dupe a lot of work and
have to manually run "gradle -b buildGradleDependency buildDep" for
every change that I want to be avail to build.gradle, but I think it
will work ok.
Any other ideas?
Are you using Gradle 0.8 or a 0.9 snapshot? 0.9 will have a few more
options.
At this stage, there's no particularly nice way to do this. And It's
hard to think of what a good solution might look like.
One possibility we've talked about is to allow you to have project
dependencies in the buildscript { } section. Then, you would split the
project into 2 projects: one which contains the reusable classes, and
another which uses them. This is similar to the buildSrc concept, except
it uses projects in the same build. Gradle would take care of compiling
the first project, before it compiles and executes the build script for
the second project.
Along similar lines, we could have some form of apply() which defers
applying the script until after the project classes have been built.
Then you could split the build script into 2 scripts: one would contain
the stuff to build the classes, and the other would contain the stuff to
use them.
I think we would get some really interesting stuff out of changing build
script evaluation so that it is a task, rather than some special case
thing. Then, you could use standard task dependencies to wire together
the above things, eg project2:evaluate dependsOn project1:classes (which
in turn dependsOn project1:evaluate).
--
Adam Murdoch
Gradle Developer
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
