This message was deleted.

In my opinion, this is the right thing to do (and no workaround):

adding an explicit task dependency to the assemble task

assemble

is a lifecycle task (has no action) which you wire with

dependsOn

. The fact that "components" are automatically built by

assemble

(is this via the archives configuration thing?) is something that is legacy (I think?) and this special behavior of

assemble

would better be removed at some point. Or replaced by a more consistent/clearer "component" concept. But that's only my take on this. 😄 Would be curious what others think. In any case, it's not good that the order or plugin application changes the behavior and I wonder if this is _just how it is_™️ or if there is something "wrong" with the setup.

Thanks, for the input. In my plugin I am not using

archives

at all, since I was operating under the assumption that

components

was preferred over the (older?)

archives

approach. The documentation seems to suggest as much, especially regarding variants and rich metadata (https://docs.gradle.org/current/userguide/publishing_customization.html#sec:publishing_custom_artifacts_to_maven) But yeah it's all a bit muddy, for instance the default java plugin also only registers a component but doesn't set up explicit task dependencies to

assemble

.