[GRADLE-1000] Use source set compile/runtime classpath for determining dependencies. Created: 22/Jun/10 Updated: 23/Jan/13 Resolved: 23/Jan/13
|Comment by Blaine Simpson [ 02/May/11 ]|
Gradle dependencies are crazy. For a build system to be adequate for professional usage, it needs to at least allow for precise control over sequence of task executions, and precise control over classpaths. At this point in time, Gradle has neither.
Compile classpaths bleed over to the runtime classpath when using java plugin. War plugin classpaths are at least usable but the rules are idiosyncratic. Why not just leverage Ivy and have predefined Ivy configs mirroring runtime names so the user can directly specify what they want for build time and for bundle and/or runtime?
|Comment by Adam Murdoch [ 02/May/11 ]|
Can you give us some more details of the precise control that you'd like? It might already be there.
|Comment by Blaine Simpson [ 03/May/11 ]|
Regarding execution sequence, that is already covered by Issue #427. I have to add distracting, superfluous tasks to use alphabetical ordering to force sequence. I don't get how a team could design and implement complex inter-project builds and such yet never have considered that there is a need to execute peer tasks in a specified order.
I'm going to rewrite the description (which was previously here) of the classpath problem with a new post, because after more testing I have learned more about the cause...
|Comment by Blaine Simpson [ 04/May/11 ]|
I understand that Gradle automatically adds compile dependencies onto the runtime classpath. Though I hate this behavior (I specified "compile" classpath, not "compile + runtime" classpath), it is understandable.
What I don't understand is why the dependencies that I am setting for my custom source set ("altRuntime") is clobbering my plain "runtime" dependency.
Output from gradle -i:
See that though I set the runtime dependency to the jstl jar file, Gradle sets my runtime classpath to the commons logging jar file. (I found by changing things that the problem goes away if I remove the alt settings, so I think Gradle is treating the altRuntime dep or classpath value is my plain runtime value).
|Comment by Luke Daley [ 23/Jan/13 ]|
It's not clear what this issue is about.
If you feel it's still an issue, please post a clarifying comment and I'll reopen it.