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.
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
