On 07/05/2012, at 11:11 AM, Luke Daley wrote: > On 06/05/2012, at 5:40 PM, Adam Murdoch <[email protected]> wrote: > >> 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. > > What do we want this for?
I think there's 2 main aspects to this: Firstly, we want to make use of the meta-data from services.gradle.org/versions, and both expose it via the tooling API, and make use of it to figure out where to download a given version from (rather than hard-coding it). This means some kind of caching/change detection/offline handling capability. Secondly, we want to treat the build environment as a real dependency of the build, in the same way that, say, we treat some library required at compile time. We already do this to some extent, in that we provision the Gradle version you need. But it's very much a second class experience relative to the goodness we offer for 'regular' dependencies. So, I think we want to reuse the goodness we have (or will have) for efficiently finding and downloading stuff: caching, up-to-date checking, progress reporting, good error messages, various transports, credentials management, offline detection, mirroring, concurrent downloads, proxy handling, and so on. > >> 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. > > I'm for 4 (which I take to imply 3) as the default sooner rather than later. > It seems to be cleaner and would be simpler for users of the tooling API > which I think should be top priority. > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
