gradle-extra-configurations-plugin icon indicating copy to clipboard operation
gradle-extra-configurations-plugin copied to clipboard

Allow Dependencies from Provided and Other Configurations Into Resulting Artifact

Open sghill opened this issue 8 years ago • 7 comments

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.

sghill avatar Feb 06 '17 23:02 sghill

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?

quidryan avatar Feb 07 '17 00:02 quidryan

+1

Helmsdown avatar Feb 09 '17 21:02 Helmsdown

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 [email protected] 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 https://github.com/nebula-plugins/gradle-extra-configurations-plugin/issues/31#issuecomment-277857173, or mute the thread https://github.com/notifications/unsubscribe-auth/AAvvFqvGHBCQgaR7wQeMl-rf-sqOkc29ks5rZ7bPgaJpZM4L42h1 .

rspieldenner avatar Feb 09 '17 23:02 rspieldenner

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.

Helmsdown avatar Feb 10 '17 00:02 Helmsdown

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.

rspieldenner avatar Feb 10 '17 00:02 rspieldenner

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)

sghill avatar Feb 11 '17 06:02 sghill

+1

qiangdavidliu avatar Feb 22 '17 21:02 qiangdavidliu