On Aug 3, 2011, at 8:34 PM, Luke Daley wrote:
>
> On 03/08/2011, at 12:20 AM, Hani Suleiman wrote:
>
>> There are a lot of very annoying transitive dependencies that get sucked in
>> when building against gradleApi().
>>
>> For example, we end up with log4j-over-slf4j, which is a thin facade for
>> log4j but does not cover the whole API. So any projects for example that try
>> to configure log4j directly will fail to compile, even if they declare a
>> dependency on log4j explicitly due to this extra jar being sucked in.
>> Similarly for jcl-over-slf4j, and probably a number of other jars that
>> should remain internal to gradle and are only required at runtime, not
>> compile time (the commons-* army, for example).
>
> Please raise an issue for this. When compiling against the Gradle API,
> Gradle's runtime shouldn't be on the compile classpath.
>
http://issues.gradle.org/browse/GRADLE-1715
> It's like it currently is due to convenience reasons, but there isn't an
> issue in the tracker to resolve this.
>
>> This to me is yet another argument why a provided configuration should be
>> supported by default!
>
> “provided” doesn't help here.
>
> What you need is something like…
>
> dependencies {
> compile gradleApi()
> runtime gradleRuntime()
> }
>
Aha, yeah I totally forgot about the runtime dependency option.
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
