On 18/11/2010, at 9:37 AM, Sean Reilly wrote: > Hi, > > Recently, my team encountered what we believed was a bug with gradle's java > dependencies. The documentation states that transitive dependencies should be > available in runtime scopes, but that only direct dependencies should be > available in compile scope. This made sense to me, so when we encountered the > opposite behaviour, I filed a JIRA issue (GRADLE-1205) with a simple > functional test case. > > Today I had some more free time, so I checked out the source code and took a > look at the source code directly, with the intent of submitting a patch. The > fix seems simple enough: mark the transitive property of the compile > configuration to false in the configureConfigurations method (this should > presumably be the case for the test configuration as well). However, looking > at the unit tests for the Java plugin, Groovy plugin, and War plugin, it > looks like the behaviour might be by design, as all of those test classes > explicitly check that compile and test configurations include transitive > dependencies. > > Is the current behaviour (transitive dependencies included) actually correct? > Or, is the documented behaviour (transitive dependencies excluded) desired?
I think that neither is really correct. For a given dependency, at compile time you want just those artifacts which define the API for the dependency. For the most dependencies, this will be the dependency jar and none of its transitive dependencies. For some dependencies, this will include the dependency jar and a small number of its transitive dependencies. And occasionally, it is the dependency jar and all its transitive dependencies. So, I think we are missing a concept here. Here's what I'd like to do: We should introduce the concept of an 'API' to Gradle. The API for a project would be defined by the publishing project, rather than a dependent project. Initially, this would consist of adding an 'api' publication of the project, similar to the 'runtime' publication each project currently has. When a dependent project is compiled, the 'api' publication would be used, and when a dependent project is executed (or bundled into a war) the 'runtime' publication would be used. A publication is simply a set of jars and a set of dependencies, so this would let you fine tune which jars and dependencies should be used at compile time, and which should be used at runtime. The default would be that the 'api' of a project contains the project's jar and no dependencies, and the 'runtime' publication contains the project's jar and its runtime dependencies. But you could tweak this to have, for example, an api jar in the 'api' publication and an impl jar in the 'runtime' publication. Once the Gradle 0.9 release is finished, we'd like to rework the dependency management DSL to introduce something like this. -- Adam Murdoch Gradle Developer http://www.gradle.org CTO, Gradle Inc. - Gradle Training, Support, Consulting http://www.gradle.biz
