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.
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()
}
Note: gradleRuntime() doesn't exist, so the above doesn't actually work.
> If I depend on gradleApi(), I'd like to depend only on the API (and
> implementation), I do not want my code to start using any of its downstream
> dependencies (or even worse, have them taint my existing dependencies). Is
> there any way of achieving this right now?
If you are going to use anything at runtime, your runtime has to include its
transitive dependencies otherwise it's just not going to work. So if you are
saying that you want to use the gradle runtime without its dependencies, that's
not possible.
--
Luke Daley
Principal Engineer, Gradleware
http://gradleware.com
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
