On 08/05/2012, at 2:55 AM, Szczepan Faber <[email protected]> wrote:
> It makes perfect sense.
>
> I just want to promote cautiousness in bringing extra dependencies to the
> tooling api.
We are talking about reducing the dependencies really.
> Granted, some dependencies are unavoidable or simply desired. I'm keen on a
> solution that is optimized for a small, single jar.
Which to me means jarjar is the solution.
>
> 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
