remove accidental connection between task outputs

[esword]

Before this PR

If a project has both the com.palantir.recommended-product-dependencies plugin and one of the distribution plugins (asset or service) then gradle8+ will fail with an error like this:

 Reason: Task 'processResources' uses this output of task 'resolveProductDependencies' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed.

The reason is that both the resolveProductDependencies and the compileRecommendedProductDependencies tasks would write into a directory called build/product-dependencies. The RecommendedProductDependenciesPlugin adds that directory as a resources source. It properly adds compileRecommendedProductDependencies as a dependency of processResources. The fact that resolveProductDependencies gets involved is a coincidence - we just happened to name it's output the same thing even though it's in a different project and plugin.

The two plugins should never be applied to the same project - something shouldn't be both an API jar with recommended dependencies and an SLS distribution that consumes them. But many repos do have both applied (likely accidentally), so this just makes it clear that the two outputs have nothing to do with each other. I may do another PR to enforce this (like we do for the Asset and Service plugins), but I want to get a release out that solves the problem first because it's blocking some repos from upgrading to gradle8.

After this PR

==COMMIT_MSG==
==COMMIT_MSG==

Possible downsides?

[changelog-app]

Generate changelog in changelog/@unreleased

What do the change types mean?

• feature: A new feature of the service.
• improvement: An incremental improvement in the functionality or operation of the service.
• fix: Remedies the incorrect behaviour of a component of the service in a backwards-compatible way.
• break: Has the potential to break consumers of this service's API, inclusive of both Palantir services
  and external consumers of the service's API (e.g. customer-written software or integrations).
• deprecation: Advertises the intention to remove service functionality without any change to the
  operation of the service itself.
• manualTask: Requires the possibility of manual intervention (running a script, eyeballing configuration,
  performing database surgery, ...) at the time of upgrade for it to succeed.
• migration: A fully automatic upgrade migration task with no engineer input required.

Note: only one type should be chosen.

How are new versions calculated?

• ❗The break and manual task changelog types will result in a major release!
• 🐛 The fix changelog type will result in a minor release in most cases, and a patch release version for patch branches. This behaviour is configurable in autorelease.
• ✨ All others will result in a minor version release.

Type

• Feature
• Improvement
• Fix
• Break
• Deprecation
• Manual task
• Migration

Description

remove accidental connection between task outputs

Check the box to generate changelog(s)

• Generate changelog entry

[carterkozak]

lgtm.

Not a change for this PR necessarily, but I wonder if we should try to map out our expected file structure within the build directory, perhaps namespaced using the plugin, then task or extension name, etc.
That could also make the contents of the build director a bit more obvious, beyond helping us avoid clobbering

Invalidated by push of bd884f5

[autorelease3]

Released 7.68.0