Implemented option to pass custom libraries as dependency

Upgraded plugin to support Gradle 7.2

Bump Gradle to 8.6 to support Java 21

fix(publish.sh): use uploadArchives instead of publishToMavenLocal

Use Artifact Registry

…lasspath, not api

Both tasks set classpath = project.configurations.api. Git history shows
this used to be configurations.compile before the Gradle 5 migration
(commit 0a020fb), where it was mechanically swapped to `api` - the wrong
1:1 replacement. `api` is a narrow "exposed dependencies" bucket; the
correct modern equivalent of the old `compile` classpath is
compileClasspath, which is what the standard Gradle javadoc task uses
by default.

The bug this causes: any type referenced in project source but pulled in
via an `implementation`-scoped dependency is invisible to these tasks,
even though the main compileJava task (which uses compileClasspath)
compiles it fine. Surfaced by availability-service's ES 9.3.5 upgrade,
where co.elastic.clients.transport.rest5_client.Rest5ClientTransport
(from elasticsearch-java, implementation-scoped) failed to resolve while
Rest5Client/Rest5ClientBuilder (from elasticsearch-rest5-client,
api-scoped) resolved fine in the same file - consistent with this
exact classpath gap.

Verified: applying this fixed plugin (published to mavenLocal) to
availability-service with elasticsearch-java back on implementation
scope makes buildMicroDocs pass with no other changes.

…xton.convention

…5, commit lockfile, explicit sourcesJar/javadocJar ordering)

…g -Werror warnings, update README

…om settings.gradle

… vintage engine

…ugin descriptor

The version-catalog alias (libs.plugins.microdocs -> id
com.maxxton.microdocs.crawler) resolves the plugin via the plugins{} DSL.
That path needs the impl jar to carry META-INF/gradle-plugins/
com.maxxton.microdocs.crawler.properties, matching the Gradle Plugin
Portal marker. The jar only shipped the legacy microdocs.properties
(id 'microdocs'), so apply failed with 'does not provide a plugin with
id com.maxxton.microdocs.crawler'. Keep both descriptors for backward
compat with apply plugin: 'microdocs' consumers.

Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>

…n marker

The plugins{} DSL / version-catalog path needs a plugin marker
(com.maxxton.microdocs.crawler:...gradle.plugin). Historically that marker
existed only on the Gradle Plugin Portal (4.0.0/4.0.1). Publish it ourselves
to maxxton-maven-registry so new versions resolve without a portal release.
Bump to 4.0.2 so consumers get a clean version rather than the cache-poisoned
4.0.1 (already resolved-and-cached broken by early CI runs).

Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>

…tep)

Cut the whole suite at 4.0.2 so ./publish.sh runs clean (4.0.2 is new
everywhere - no 409 on the immutable core-java 4.0.1) and versions are
coherent instead of core 4.0.1 / doclet 4.0.0 / crawler 4.0.2.

Note: crawler-gradle and the doclet still pin microdocs-core-java:3.0.0,
so core-java's 4.x line remains unwired - tracked as a follow-up.

Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>