Allow Dependencies from Provided and Other Configurations Into Resulting Artifact

[sghill]

If a dependency is declared as provided and another configuration that is included in resulting artifacts (such as compile or runtime), it should not remove the dependency from the artifact.

[quidryan]

Correct me if I'm wrong, this was on a web-app, where the provided configuration was created by the war plugin and not by the extra-configurations-plugins. Is this a core gradle bug?

[Helmsdown]

+1

[rspieldenner]

This is the behavior in gradle. So we emulate exactly what the providedCompile from the war plugin does. I wouldn't consider it a bug. On Mon, Feb 6, 2017 at 4:12 PM Justin Ryan <notifications@github.com> wrote: Correct me if I'm wrong, this was on a web-app, where the provided configuration was created by the war plugin and not by the extra-configurations-plugins. Is this a core gradle bug? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#31 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAvvFqvGHBCQgaR7wQeMl-rf-sqOkc29ks5rZ7bPgaJpZM4L42h1> .

[Helmsdown]

The behavior I've seen is as follows:

1. dependency X is a specified as a provided dependency of my build
2. dependency X has transitive dependencies (A, B, and C)
3. dependency Y is specified as a compile dependency of my build
4. dependency Y has transitive dependencies (which include C)
5. dependency C is NOT included in my war (even though it should be because Y depends on it)

@sghill @quidryan can you confirm if this matches what you have seen? if so, at the very least the documentation for "provided" should explicitly call this out. It seems to me that the transitive dependencies of Y should be included in my war, regardless of whether X happens to have transitive dependency overlap.

[rspieldenner]

That is the behavior that our provided performs just like it is the behavior that providedCompile from the war plugin performs. You have told gradle that dependency X and all of its transitives will be provided, since why would X be provided by the system but not A, B, and C.

I would be happy erroring or warning on the build that you have specified something that can't be resolved.

[sghill]

Confirming this is how providedCompile, compileOnly, and provided work with this example project: https://github.com/sghill/gradle-configurations-war-example

@Helmsdown Yes, that matches what I have seen. I also like @rspieldenner's idea of erroring or warning on the build since this behavior is almost never what is intended.

There is another scenario that may need a new configuration:

1. I depend on something I only want to use in development, like an embedded server
2. My development dependency should not end up in the resulting artifact (ruling out compile)
3. My development dependency must be available on the runtime classpath of the IDE. I also need the transitive dependencies that overlap with the development dependency to be included in the resulting artifact. (ruling out compileOnly and provided)

[qiangdavidliu]

+1