Don't auto-attach all output artifacts for a project to the assemble task

mkobit commented 6 years ago

I originally asked about this on the forum at https://discuss.gradle.org/t/why-does-assemble-run-my-task-when-it-is-not-attached-to-the-archives-or-default-configurations/28718 before diving in to understand the behavior.

Expected Behavior

Behavior is documented in https://docs.gradle.org/current/userguide/base_plugin.html or the behavior is changed/removed
artifacts / publications / configuration.getOutgoing().artifact(...) alignment and clear path for multi-project builds with different types of artifacts

Current Behavior

Discussed in https://discuss.gradle.org/t/why-does-assemble-run-my-task-when-it-is-not-attached-to-the-archives-or-default-configurations/28718 and also behavior of base plugin shown at https://github.com/gradle/gradle-native/issues/730#issuecomment-395493684

Context

We have a polyglot multi-project where we use outputs from some projects as dependencies in other projects. We do this instead of reaching into the other projects' models to have clean separation and optimize for parallelism. This usually takes the form of someConfiguration.outgoing.artifact(someTask.regularOutputFileProperty) where someTask.regularOutputFileProperty is a RegularFile/RegularFileProperty and where consumers would use dependencies { myConfiguration(project(path = ":someProject", configuration = "someConfiguration")) }.

Steps to Reproduce (for bugs)

plugins {
  id("base")
}

final myTask = tasks.create("myTask") {
  doFirst {
  }
}

configurations.create("someConfig") {
  outgoing.artifact(file("someFile.txt")) {
    builtBy(myTask)
  }
}

./gradlew assemble runs myTask

Your Environment

Gradle 4.10.2, but many versions exhibit this behavior

ghale commented 6 years ago

stale[bot] commented 4 years ago

This issue has been automatically marked as stale because it has not had recent activity. Given the limited bandwidth of the team, it will be automatically closed if no further activity occurs. If you're interested in how we try to keep the backlog in a healthy state, please read our blog post on how we refine our backlog. If you feel this is something you could contribute, please have a look at our Contributor Guide. Thank you for your contribution.

eskatos commented 4 years ago

Also see a similar report at https://github.com/gradle/gradle/issues/14065

melix commented 4 years ago

This would go away with the deprecated configurations removals in 7.0 (see PR above)

melix commented 3 years ago

So because we cannot remove the archives configuration in 7.0 yet, I think this has to be deferred to 8.0. Alternatively, we could introduce an experimental flag to disable auto-attachment of artifacts to the archives configuration.

melix commented 3 years ago

Confirmed that this has to be designed properly given the constraints on archives and cannot be done for 7.0. I'm setting the milestone to 7.1 so that maybe we can enable something with a feature preview.

This relates to https://github.com/gradle/gradle/issues/15639

jjohannes commented 2 years ago

Since it has not been mentioned here yet:

You should set isVisible = false on the configuration to which you add the artifact(s). Then it won't be automagically added to archives and with that being made part of assemble.

See: https://github.com/gradle/gradle/blob/0f44d07bcfbd9c3657a5f22eb3381a471cd2517b/subprojects/plugins/src/main/java/org/gradle/api/plugins/BasePlugin.java#L107

melix commented 2 years ago

After years I finally understand the purpose of the visible flag, thank you Jendrik!

gradle / gradle