How would i go about excluding them? Since they are dependencies of project B - i am only saying that project A depends on project B. Is there a way that i can say something like “project A depends on project B, except for these configurations within project B”?
I think you could add a ‘provided’ configuration in project A that references all dependencies from project B’s ‘provided’ configuration and then exclude all of them from test source set’s runtime classpath, something like:
configurations {
provided
}
dependencies {
provided project(path: ':B', configuration: 'provided')
}
sourceSets.test.runtimeClasspath -= configurations.provided
Seems like an awful lot to do just to get a simple cross-project dependency to work 
I’ll give it a whirl and see what happens.
I was able to get it to work by doing this in my root project’s build.gradle (note we already have the “provided” configuration defined in our plugin so I don’t have to introduce it here):
project(':A') {
dependencies {
compile project(':B')
}
sourceSets.test.runtimeClasspath -= project(':B').configurations.provided
}
If you have a plugin that adds the ‘provided’ configuration, then why does it configure the ‘default’ configuration to extend it? Would not it be better if the plugin modifies the ‘main’ and ‘test’ source sets’ classpaths to include it? This way if somebody resolves your modules it won’t get the provided dependencies automatically and will not have to filter them out as you did above.
The plugin currently introduces the provided configuration and then has the compile configuration extend it. I saw that pattern on some forum somewhere a while ago when we were looking for a replacement of mavens provided scope.
Is that not the way it should be? Anything considered to be provided is required as a compile time dependency.
The dependencies of the ‘provided’ configuration can be added as compile/runtime dependencies by modifying the source set’s classpath(s) instead of making the ‘compile’ configuration extend the ‘provided’. This has the benefit that if somebody defines a dependency to your module(s), they will not get the provided libraries:
configurations {
provided
}
sourceSets.main.compileClasspath += configurations.provided
sourceSets.main.runtimeClasspath += configurations.provided
The other benefit of this approach is that when you are packaging your product, you will not have to exclude the ‘provided’ libraries. If ‘compile’ configuration extends ‘provided’, you will have to exclude them otherwise they will become part of your package (e.g. war) while they should not be since they are provided by the underlying container.
I guess both approaches are valid, but I prefer the one above rather than what your plugin implements.
So did you find out which provided jar caused the exception during Spring context initialization?
One side-effect I’ve noticed doing it this way - when the javadoc task runs it errors out on classes that have imports to classes that are part of the provided configuration.
Yes, with this approach any tasks that assume the ‘compile’ or ‘runtime’ configurations contain all dependencies must be reconfigured to include the ‘provided’ dependencies as well - javadoc is one example, but also the eclipse’s classpath if using eclipse plugin, possibly others too.