On Mon, May 7, 2012 at 3:11 AM, Luke Daley <[email protected]> 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? > > > 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. > So guava is a new tooling api dependency introduced in 1.1? It would be nicer to ship tooling api without it. I like #1 option first because tooling api is very small and shouldn't need that much externals. I'm ok with #3 + #4 but not hugely. Ideally, I'd like a single jar that is small (which means options 1+3/4). Cheers! > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > -- Szczepan Faber Principal engineer@gradleware Lead@mockito
