Tom, Thanks for your reply. I think I did try adding test-classes to unmanagedClasspath and that introduced some other problem. A week after my original question I already don't remember what the problem was :)
We decided not to go with Gradle, I'm sorry to say, and chose Gant. Here's our story in brief, in case anyone's interested. We have a project with lots of modules (more than 100 is expected). Everyone here uses IntelliJ IDEA, so we decided to use IDEA's .iml and .idea files as the primary source of inter-module and library dependencies. We don't care much about libraries' transitive dependencies, we store all libs in svn and don't enjoy any downloading from the Internet during build. We used to produce parts of Ant script with XSLT transformation from the original source of inter-module dependencies. That would give us targets compile.A, compile.B, and so on - and also classpaths, testing and other targets and stuff up to the stage where all artifacts are bundled together. That was terrible to write and even to look at, I must say. With Gant, the horror of XSLT is gone. We have a single closure that produces per-module targets for module X. All other problems with Ant, like lack of "if"s, are gone. Parsing IDEA's files is trivial. Everything's perfect. Gee, you can even debug your script in IDEA! Gradle is everything Gant is, and more? Right. With Gradle, we found another level of complexity and obscurity introduced. To understand what's going on or how to do something, current documentation is hardly enough. I've had to go through the source code quite a few times and browse this mailing list. Learning ivy seems very necessary. The API is far from obvious (why on Earth to add a library to classpath I have to call something named addClientModule? what does the "name" parameter mean and why it should be "lib"? /rhetorical questions/). I hope I didn't miss something obvious about Gradle that would turn it from magic into science for me. I understand the project is still in its early versions, and I'm totally enthusiastic about any tools that would reduce the complexity of build scripts for projects like ours. I understand that complexity is replaced with conventions sometimes, but I believe those must be open and easily configurable, otherwise the cost beats the purpose. So guys, thanks again for your effort, I hope to take a look at Gradle sometimes later. If you need more input about our use case, feel free to write me. Cheers, Igor Tom Eyckmans wrote: > > 2009/3/30 Igor Sereda <[email protected]> > >> >> Hello to the list. >> >> I'm trying to set up a Gradle build instead of overly complex Ant build. >> So >> far it looks promising, so thanks and kudos to Hans and guys! > > Thanks! > >> >> >> The first bump for me is that, from what I see, test classes in one >> project >> are not available in test classpath in another project within the same >> build. >> > >> >> The build.gradle looks something like that: >> >> project(":A") { >> dependencies { >> testCompile ':junit:0' >> } >> } >> >> project(":B") { >> dependencies { >> compile project(':A') >> testCompile project(':A') >> testCompile ':junit:0' >> } >> } >> >> Some tests in B use fixtures and stuff defined in test sources in A. The >> classpath used to compile B tests includes main classes from A but not >> test >> classes. >> >> Am I missing something here? > > I don't think so, it is just not done automatically at the moment, but I > think it is a good idea to make this possible. I wouldn't make it the > default but make it so that when you declare a dependency on project A in > B > in the testCompile dependency configuration you are depending on the test > configuration of project A. > > >> If that's on purpose, is there a workaround? >> > > Yes there is a workaround, you can add the build/test-classes directory of > project A to the unmanagedClasspath attribute of the test task in the > project B build file. > > > -- View this message in context: http://www.nabble.com/Test-classes-dependency-in-multi-project-builds-tp22787955p22906955.html Sent from the gradle-user mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
