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
