On Wed, Nov 17, 2010 at 21:00, Adam Murdoch <[email protected]> wrote: > > 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 > >
This is an excellent idea IMO Adam. I wish maven had this from the start, it would have really helped alleviate dependency problems. +1 -- Jason Porter http://lightguard-jp.blogspot.com http://twitter.com/lightguardjp Software Engineer Open Source Advocate PGP key id: 926CCFF5 PGP key available at: keyserver.net, pgp.mit.edu --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
