> > 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.
Maybe I'm missing something, but aren't all of these relatively easy to accomplish with gradle's existing functionality? 1. The dependency and none of its transitive dependencies: if I submit the patch I already have working, this will be the default, which is imo appropriate as it's the most likely case. 2. The dependency and a small number of transitive dependencies: Add the few specific dependencies explicitly as direct dependencies. 3. The dependency and all of its transitive dependencies: Add that specific dependency with transitive = true on the dependency itself. It's currently possible to handle all of those cases. Imo, it's currently quite easy to handle cases #1 and #3. A specific syntax for case #2 might help, but it might cause problems too: - What if upgrading the direct dependency changes the version of the transitive dependency? - What if a new version of the direct dependency no longer includes the transitive dependency, but the code being compiled still needs it? I believe that the safe solution for this case is that if a dependency is both direct and transitive, mention it twice. To be honest, I haven't encountered this case often enough to worry about it. Are there many complaints about this functionality right now? If others are inconvenienced by this more than I am, maybe it is worth it; but I wouldn't worry about it unless there are many requests for improvement. All in all the api functionality, while elegant, sounds like a solution to a problem that I don't have, or at least a problem that I don't have yet. Until that time; any thoughts on the proposal to just change the current default? Sean On Thu, Nov 18, 2010 at 4:00 AM, 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 > >
