Hi, I've been gradually moving the things that the tooling API client uses out of the core project, into projects like base-services and messaging. The idea here is to decouple the tooling API client from core, so that we can start publishing core, and every project, with their real dependencies declared. Right now, only a handful of projects are published, and the meta-data declares only those dependencies that are needed in order to be used by the tooling API. This is to avoid dragging a whole heap of stuff into the tooling API (e.g. groovy, ant, ivy, http-client, and so on).
One question is to do with the real dependencies of the tooling API. At the moment, it drags in slf4j and guava. I'm not too concerned about slf4j, as this is effectively part of the interface between the tooling API and the client, as much as the tooling API itself is. Guava is potentially more of a problem, as its usage is internal to Gradle, and even though Guava seems pretty good at backwards compatibility, we are forcing a particular version on the client. In addition, at some point we're going to want to reuse some of our remote resource/http transport/caching stuff in the tooling API, which drags in a bucketload of stuff. Some options: 1. Avoid using any external stuff in the tooling API. 2. Keep the number of dependencies small, but expose them to the client. 3. Jarjar the internal dependencies into the base service jar or tooling API jar. 4. In a similar vein, offer a variant of the tooling API that embeds all its internal dependencies. Might make a nice plugin to offer API developers at some point. Thoughts? I think we just go with 2. for now, and maybe 4. once our support for publishing variants is further along and/or we have more tooling API dependencies. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
