I'm using 0.8, but no reason why I can't switch to 0.9. Is there a way to call build.gradle from another build.gradle? This way I could avoid the awkward "gradle -b buildGradleDep.build target"
It's a pretty tough problem to solve in a compiled language. Ruby/Rake doesn't have this problem because the build script wouldn't break unless it actually tried to execute the task in question. I don't know if it's feasible or even a good idea to tag a task not to be precompiled... but that's one way of dealing with it. On Tue, Mar 23, 2010 at 6:38 PM, Adam Murdoch <[email protected]> wrote: > > > 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 > > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
