prerelease-link.sh: no <pluginRepositories> block, so metaobjects-maven-plugin never resolves from the private registry

[dmealing]

Found while evaluating 0.24.0-rc.3 in an adopter project.

Summary

link_mvn() writes a <repositories> block, but never a <pluginRepositories> block. Maven resolves plugins exclusively from <pluginRepositories> — <repositories> does not apply to them.

Any consumer that uses metaobjects-maven-plugin (i.e. anyone doing Maven-side codegen, which is the main reason to depend on MetaObjects from Maven at all) therefore cannot build after a successful link.

$ grep -c 'pluginRepositor' tools/prerelease/prerelease-link.sh
0

Observed

link reports success and repins <metaobjects.version> correctly:

  repinned com.metaobjects dependencies to 7.24.0-rc.3 (via <metaobjects.version>)
✓ linked. Install/restore, then iterate:
  maven  mvn -U compile

Running exactly the command it prints:

Downloading from central: https://repo.maven.apache.org/maven2/com/metaobjects/metaobjects-maven-plugin/7.24.0-rc.3/metaobjects-maven-plugin-7.24.0-rc.3.pom
[WARNING] The POM for com.metaobjects:metaobjects-maven-plugin:jar:7.24.0-rc.3 is missing, no dependency information available
[ERROR] Plugin com.metaobjects:metaobjects-maven-plugin:7.24.0-rc.3 or one of its dependencies could not be resolved:
[ERROR] 	Could not find artifact com.metaobjects:metaobjects-maven-plugin:jar:7.24.0-rc.3 in central (https://repo.maven.apache.org/maven2)

Note it goes to central — the private registry is configured, but not for plugin resolution, so Maven never asks it.

The build dies in the first module that binds the plugin, before any codegen runs. Library-only consumers (dependencies but no plugin) are unaffected, which is probably why this has not been hit before.

Suggested fix

Emit both blocks inside the same managed markers, so unlink's strip_block continues to remove everything in one pass:

<!-- >>> metaobjects prerelease (managed) >>> -->
<repositories>
  <repository>
    <id>metaobjects-prerelease</id>
    <url>.../api/packages/<owner>/maven</url>
    <releases><enabled>true</enabled><updatePolicy>always</updatePolicy></releases>
    <snapshots><enabled>true</enabled><updatePolicy>always</updatePolicy></snapshots>
  </repository>
</repositories>
<pluginRepositories>
  <pluginRepository>
    <id>metaobjects-prerelease</id>
    <url>.../api/packages/<owner>/maven</url>
    <releases><enabled>true</enabled><updatePolicy>always</updatePolicy></releases>
    <snapshots><enabled>true</enabled><updatePolicy>always</updatePolicy></snapshots>
  </pluginRepository>
</pluginRepositories>
<!-- <<< metaobjects prerelease (managed) <<< -->

Workaround for adopters today

Add the <pluginRepositories> block by hand inside the managed markers link wrote — placing it there keeps unlink round-trip-clean. Verified: with it added, the same mvn -U compile resolves the plugin from the private registry and the full reactor builds against the RC.

[dmealing]

Fixed on main — the Maven link now writes a <pluginRepositories> block alongside <repositories>, so metaobjects-maven-plugin resolves from the private registry rather than only the dependencies do.