baseline-java-versions: Regard projects as applicable for `libraryTarget` iff they have a jar publish plugin

[CRogers]

Before this PR

Currently we are very conservative with what we choose to be "published library" vs "distribution only" code in baseline-java-versions. If there is any hint of publishing, even if there are no publications, we regard the project as a published library.

Internally, lots of repos have Gradle projects that are internal only (no jar is published) but happen to publish some non-jar resource (eg conjure or audit-schema). baseline-java-versions currently regards these as libraryTarget despite being internal only. People have started to use the hidden override... property to fix it, which is less than ideal: it should just do the right thing.

After this PR

==COMMIT_MSG== baseline-java-versions is now much less conservative about what it regards for libraryTarget instead of distributionTarget. libraryTarget will be used if and only if a jar is published using one of the Palantir jar publish plugins. ==COMMIT_MSG==

Possible downsides?

• What about Gradle plugins etc bundled into maven-bundles? Is this going to now make them distributionTarget? Similar question for other jar based stuff packaged into maven bundles and run in prod (flink? magritte?)

---

I think baseline-java-versions needs a complete overhaul. This PR is a patch more than anything and the plugin still has some deep problems:

• It's very much in a "working by accident" state, as now Gradle requires the JDK levels very early on in the build, which just happens to be after the publish-jar plugin is applied. If it were just a bit earlier, it would not work.
• The providers to work out the target/runtime versions are called many times throughout the build and produce different values depending on the time they are called. Finalising them on read breaks everything at it finalises a calculation that's too early.
• It's very hard to work out why a project is a certain runtime/target without running with extra logging.
• Some situations it's just wrong (eg libraryTarget test code depends on testing library project that is now marked as distributionTarget). Ideally it needs to take into account all the dependents for each project.

All of these could probably be solved by having lock files in each project. Then we can work out library vs distribution target later in the build ie at task input property calculation time rather than super early on in configuration time - then we could actually look at publications and inter-project dependencies etc safely

[changelog-app[bot]]

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
• [x] Fix
• [ ] Break
• [ ] Deprecation
• [ ] Manual task
• [ ] Migration

Description baseline-java-versions is now much less conservative about what it regards for libraryTarget instead of distributionTarget. libraryTarget will be used if and only if a jar is published using one of the Palantir jar publish plugins.

Check the box to generate changelog(s)

• [x] Generate changelog entry

[stale[bot]]

This PR has been automatically marked as stale because it has not been touched in the last 14 days. If you'd like to keep it open, please leave a comment or add the 'long-lived' label, otherwise it'll be closed in 7 days.