KT-64377 Maven dev publish

[adam-enko]

Use project-local Maven dev repos for integration testing.

Impact

Using a Maven Repo is useful for integration tests, because it verifies that the artifacts are published correctly with the expected coordinates. It is also useful for Gradle Plugins, because we can verify that the plugin marker was correctly published.

Removing the dependency on Maven Local is one of the last steps before Dokka's build logic (just the build logic, not Dokka Gradle Plugin!) can be made fully Config Cache compatible.

Verification

To test locally, you can use configuration cache:

./gradlew :dokka-integration-tests:check --configuration-cache --configuration-cache-problems=warn

(Although there will be warnings, they can be ignored - Dokka build scripts (not DGP!) will be made CC compatible in upcoming PRs.)

Summary

• Plugin dev.adamko.dev-publish publishes subprojects to a project-local directory.

  Benefits:

  • compatible with: config cache, build cache, isolated projects
  • Unlike the standard Gradle publication, snapshot versions will not constantly be re-published. (publishToMavenLocal will also not constantly republish snapshot versions, but it's not easily possible to change the location of Maven Local)
  • doesn't use Maven Local, so there's no chance of cross-contamination with outdated artifacts or other projects

• Dynamically inject the local Maven dir:

  • Gradle projects: find/replace /* %{PROJECT_LOCAL_MAVEN_DIR}% */ with an exclusive Maven repo
  • Maven projects: provide a settings.xml with the local plugin repo.

[IgnatBeresnev]

Tremendous work with this and all the prerequisites, thanks!

Unlike the standard Gradle publication, snapshot versions will not constantly be re-published. (publishToMavenLocal will also not constantly republish snapshot versions, but it's not easily possible to change the location of Maven Local)

Isn't that the whole point of -SNAPSHOT versions, that they are re-published every single time regardless of everything? Or perhaps I misunderstood you about when it doesn't do re-publishing compared to how it works now?

Say, I have 2.0.0-SNAPSHOT now, I run integration tests and I now have a local Maven repo with Dokka 2.0.0-SNAPSHOT. Then I introduce a breaking change in dokka-base (something obvious such as throwing an exception on start), and run integration tests again without doing clean - will a new version be published, or will the tests use the version published previously and thus pass?

[adam-enko]

Isn't that the whole point of -SNAPSHOT versions, that they are re-published every single time regardless of everything? Or perhaps I misunderstood you about when it doesn't do re-publishing compared to how it works now?

When publishing to repos, yes, Gradle will always publish a new version.

This is okay for testing: because we're using a local repo for testing, publishing is effectively a 'zip & copy files' operation, which is cheap and quick to do, and isn't worth caching.

Say, I have 2.0.0-SNAPSHOT now, I run integration tests and I now have a local Maven repo with Dokka 2.0.0-SNAPSHOT. Then I introduce a breaking change in dokka-base (something obvious such as throwing an exception on start), and run integration tests again without doing clean - will a new version be published, or will the tests use the version published previously and thus pass?

Yes, Gradle will detected that the source files changed, so it will re-run the compilation tasks. The resulting files will be packaged and re-published.