It makes perfect sense. I just want to promote cautiousness in bringing extra dependencies to the tooling api. Granted, some dependencies are unavoidable or simply desired. I'm keen on a solution that is optimized for a small, single jar.
Cheers! On Tue, May 8, 2012 at 4:16 AM, Adam Murdoch <[email protected]>wrote: > > On 07/05/2012, at 3:48 PM, Szczepan Faber wrote: > > 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. > > > The tooling API consumer touches more than you think: > * Classloading and classpath handling. > * Concurrency. > * In-process messaging (in particular eventing). > * Progress reporting and logging. > * HTTP download and caching. > * Gradle meta-data, such as where to find distributions, the build layout, > the build environment configuration, and so. > > We want to reuse the infrastructure we already have for this stuff. > However, I don't think it's reasonable to say: anything reachable from the > tooling API must not have any external dependencies. This is a problem for > a few reasons: firstly, it means either artificially splitting out stuff > that happens to be used by the tooling API into separate projects, or it > means that I, as a developer, need to know what stuff is transitively > reachable from the tooling API. Secondly, it means reimplementing stuff for > which there are excellent external libraries. I don't really want us to > implement a bunch of stuff for collection handling that guava already > provides. > > So, bottom line is that the tooling API will have external dependencies. > We need a solution that will deal with this. > > > > 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). > > > Given that jarjar can strip out stuff that isn't needed, we may find that > the combined (baseServices + messaging + toolingAPI + guava) jar is > actually much smaller than the current (baseServices, messaging, core, > toolingAPI) download. For example, none of the remote messaging stuff will > be included, or the cli parser, or what ever. > > > -- > Adam Murdoch > Gradle Co-founder > http://www.gradle.org > VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting > http://www.gradleware.com > > -- Szczepan Faber Principal engineer@gradleware Lead@mockito
