We are aware of this problem. The underlying Ivy behavior is kind of surprising. If an ivy configuration sets transitive to false, a transitive=true of a dependency is ignored. What Gradle should do to solve this, is to set an ivy configuration transitive value always to true. The Gradle configuration transitive value will then be just the default value for the transitive value of the dependencies. Which can be overridden as in the case above.

In fact this even points to some other problem. We have the policy that the compile configuration resolves non-transitively. I think the objective behind this is still valid. But for example for Groovy code this does not work as Groovy also needs the transitive dependencies in the classpath for compiling. With Jetty the same seems to be the case. I would be interested how this can be the case for a Java project. Therefore I think we should change our strategy. compile should resolve transitively but the code-quality check should spit our warnings or make the build fail, if transitive dependencies are directly used in the source code.

Ok, I see what you're saying. You're saying that because of the way Jetty is packaged the compiler will fail if the class hierarchy is not entirely present on the classpath.

Actually, I think that when a dependency is explicitly declared as transitive gradle should accept this at compile time. The user may not know what he or she is doing but it's not reasonable to assume gradle can fix that problem.

About the code-quality checks, this is probably a good idea. If I want to compile against classes I should explicitly import all the jars I need. Actually, I'm pretty sure you can do this with BCEL after compilation so that this check could become part of gradle. I've recently implemented an import checker based on this article and it worked like a charm:

http://illegalargumentexception.blogspot.com/2008/04/java-finding-binary-class-dependencies.html

I've factored out the jdepend/bcel code I wrote recently which could form the basis of a gradle plugin.

To give you an idea of what it does, here's some output:

Seen poc.jdepend.visitor.JDependWalker
poc.jdepend.visitor.JDependWalker extends java.lang.Object
poc.jdepend.visitor.JDependWalker imports poc.jdepend.visitor.JDependWalker
poc.jdepend.visitor.JDependWalker imports java.lang.Object
poc.jdepend.visitor.JDependWalker imports java.io.IOException
poc.jdepend.visitor.JDependWalker imports jdepend.framework.JDepend
poc.jdepend.visitor.JDependWalker imports java.util.Collection
poc.jdepend.visitor.JDependWalker imports java.util.Iterator
poc.jdepend.visitor.JDependWalker imports jdepend.framework.JavaPackage
poc.jdepend.visitor.JDependWalker imports jdepend.framework.JavaClass
poc.jdepend.visitor.JDependWalker imports poc.jdepend.visitor.ClassVisitor
poc.jdepend.visitor.JDependWalker imports java.lang.String
poc.jdepend.visitor.JDependWalker imports java.util.ArrayList
poc.jdepend.visitor.JDependWalker imports org.apache.bcel.Repository
poc.jdepend.visitor.JDependWalker imports poc.jdepend.visitor.JDependWalker$1DependencyEmitter
poc.jdepend.visitor.JDependWalker imports org.apache.bcel.classfile.DescendingVisitor
poc.jdepend.visitor.JDependWalker imports java.util.Collections
poc.jdepend.visitor.JDependWalker imports org.apache.bcel.classfile.JavaClass
Seen poc.jdepend.visitor.ClassVisitor
poc.jdepend.visitor.ClassVisitor extends java.lang.Object
poc.jdepend.visitor.ClassVisitor imports poc.jdepend.visitor.ClassVisitor
poc.jdepend.visitor.ClassVisitor imports java.lang.Object

Hi Steven, I thought I had already commented on that. But I can't find it. Having such a plugin would be very cool. Could you create something like a GitHub project with the stuff you extracted from jdepend?

The compile configuration is now resolved transitively by default. So your Jetty stuff will just work now.

As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

• Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
• Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

Thanks again for reporting this issue. We haven't heard back from you after our inquiry from November 15th. We are closing this issue now. Please create an issue on GitHub if you still feel passionate about getting it resolved.