Onboard Maven restores to CFS

[Ahmed Muhsin (ahmedmuhsin)]

Summary

• Route Maven dependency and plugin restores through the upstream-public CFS feed in every module.
• Install the repository Maven mirror and authenticate it before public and official CI builds.
• Resolve the Application Insights agent through Maven instead of downloading it directly from Maven Central.
• Add local credential-provider helpers for ingesting uncached packages.

This follows the Maven onboarding pattern from Azure/azure-functions-openai-extension#218.

Validation

• Authenticated CFS reactor package build under Java 11
• Authenticated CFS package build for the Java 17 MCP module
• Application Insights agent copy through Maven and CFS
• Parsed all six tracked POMs and verified their dependency and plugin repositories use CFS
• Exercised the PowerShell credential-provider bootstrap using a disposable Maven repository
• Validated PowerShell and Bash helper syntax

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[Swapnil Nagar (swapnil-nagar)]

...

[Swapnil Nagar (swapnil-nagar)]

Overall Assessment

CFS Maven onboarding for the additions repo — 15 files, 6 POMs (root + 5 modules), 2 CI templates, credential-provider scripts, and docs. Consistent with the companion PRs in azure-functions-java-library (#239) and azure-functions-java-worker (#889). All 5 CI checks pass. Findings below, including one inconsistency specific to this repo's multi-module layout.

---

Issues

1. [Worth confirming] Root pom.xml omits the sonatype-nexus-snapshots plugin-repository override that all five module POMs carry

The five module POMs (azure-functions-java-core-library, azure-functions-java-mcp, azure-functions-java-opentelemetry, azure-functions-java-sdktypes, azure-functions-java-spi) each declare two pluginRepository entries: central and an override for sonatype-nexus-snapshots pointing at CFS. The root pom.xml declares only the central plugin repository — no sonatype-nexus-snapshots override.

If the root POM (or a parent it inherits from) ever resolves a plugin through an inherited sonatype-nexus-snapshots repository, that request would bypass CFS and hit oss.sonatype.org directly. Please confirm the root build does not inherit a sonatype-nexus-snapshots plugin repository — if it does, the override is needed there too for consistency and to keep all plugin traffic on CFS.

---

2. [Nit] The CFS feed URL is now duplicated across 6 POMs plus settings.xml

https://pkgs.dev.azure.com/azfunc/public/_packaging/upstream-public/maven/v1 appears in every repository/pluginRepository block across all six POMs and again in the settings.xml mirror. This is inherent to the pattern (the pom overrides cover the anonymous path; the mirror covers plugins/extensions and CI), but with six POMs the duplication is more pronounced than in the single-POM repos. If the feed URL ever changes, all of these must be updated together. Consider a <properties> entry (e.g. <cfs.feed.url>) referenced by each block to centralize it, if the generator/tooling allows.

---

3. [Minor] PowerShell here-string indentation produces leading whitespace in generated .mvn/extensions.xml

In eng/scripts/Install-MavenCredentialProvider.ps1, the @""...""@ here-string is indented at code level, so every line written to .mvn/extensions.xml carries leading spaces. The XML is valid and Maven parses it, but it is inconsistent with the Bash script's column-0 heredoc. Consider outdenting the here-string content (and its closing ""@) to column 0.

---

4. [Low] build.ps1 — mvn dependency:copy relies on the CI settings-copy step having run first

The Application Insights agent restore (& mvn @mavenArguments using maven-dependency-plugin:copy) doesn't pass -s settings.xml; it depends on the Install Maven settings.xml step in build.yml / build-and-test.yml having already written the mirror to ~/.m2/settings.xml. The ordering is correct in both templates, but a one-line comment in build.ps1 noting the assumption would prevent future breakage.

---

5. [Worth confirming] Snapshots enabled on the CFS central repository

Each new central repository enables both releases and snapshots. Any snapshot dependency not yet ingested into the feed will fail anonymously. Please confirm all snapshot dependencies across the six modules are either eliminated or already cached in upstream-public.

---

6. [Very minor] install-maven-credprovider.sh version regex

grep -qE ""<version>[[:space:]]*${version//./\\.}[[:space:]]*</version>"" — the `` substitution is correct (produces a literal-dot ERE) but slightly confusing. A comment, or [.] instead, would read clearer. Not a bug.

---

Positives

• .gitattributes: enforces LF on *.sh — correct for cross-platform script integrity.
• .gitignore: ignores .mvn/ with a clear comment on why committing it breaks anonymous restore.
• build.ps1: replacing the direct Invoke-WebRequest from Maven Central with mvn dependency:copy through CFS is the right move; maven-dependency-plugin:3.8.1 is pinned; StopOnFailedExecution preserves existing error handling.
• CI templates: install-settings → MavenAuthenticate@0 → build ordering is correct in both, with a helpful comment explaining why the mirror must precede authentication.
• Module POMs: the sonatype-nexus-snapshots override is correctly present in all five modules (see Updated release version to 1.0.0-SNAPSHOT #1 re: the root).
• Credential-provider scripts: idempotent, temp-dir bootstrapped outside any Maven project, reliable cleanup (finally / trap EXIT), actionable errors.
• Security: no credentials committed; README directs PATs to the user-level ~/.m2/settings.xml only.
• Docs: thorough README onboarding section.

---

Summary

Area	Finding	Severity
Root pom.xml	Missing sonatype-nexus-snapshots plugin override present in all 5 modules	Worth confirming
6 POMs + settings.xml	CFS URL duplicated in many places — consider centralizing	Nit
Install-MavenCredentialProvider.ps1	Here-string indentation leaks into generated XML	Minor
build.ps1	Silent ordering dependency on CI settings copy — add comment	Low
All central repos	Snapshots enabled — confirm all snapshots cached in feed	Worth confirming
install-maven-credprovider.sh	Version regex correct but could use a comment	Nit

The PR is approvable. The most useful pre-merge checks are #1 (root vs module plugin-repo consistency) and #5 (snapshot coverage in the feed).

[Swapnil Nagar (swapnil-nagar)]

Review the comment by agent

[Ahmed Muhsin (ahmedmuhsin)]

Confirmed on the current head:

• The root POM has no parent and its effective dependency/plugin repository IDs are only central; no sonatype-nexus-snapshots repository is inherited.
• No parent, dependency, or plugin coordinate in any of the six POMs uses an external SNAPSHOT version.
• The repeated feed URL is intentional because these modules are independent Maven roots; the POM entries cover normal builds while settings.xml covers early plugin resolution and CI credentials.
• The PowerShell here-string content is already at column zero and matches the merged reference.
• d99ad41 documents the CI settings dependency in build.ps1.
• The Bash regex matches the validated reference implementation.

No further code change is needed for these findings.

[Ahmed Muhsin (ahmedmuhsin)]

Correction to my last comment. I said no further code change was needed and that was wrong.

The 1ES network isolation task in this PR's build reports CFSClean2 as NOT COMPLIANT with 10 connections to oss.sonatype.org. That task watches live build traffic rather than file contents, which is why scanning the source came back clean.

The cause is build.ps1 cloning and building azure-maven-plugins. Its azure-functions-maven-plugin pom declares a download repository under the id maven.snapshots pointing at Sonatype, and our mirror was scoped to central, so that id was never redirected.

44c5558 scopes the mirror to external:*. I verified locally that maven.snapshots, sonatype-nexus-snapshots and central all resolve through the feed now.

For context on where this stands, dev reports CFSClean NOT COMPLIANT with 57 violations and CFSClean2 with 18. This PR already brought CFSClean to compliant and CFSClean2 down to 10. The new run should show whether it reaches zero.

[Ahmed Muhsin (ahmedmuhsin)]

CI confirms it. Build 296478 is green and the network isolation task now reports every CFS policy compliant.

Policy	dev	previous run	now
CFSClean	NOT COMPLIANT (57)	COMPLIANT	COMPLIANT
CFSClean2	NOT COMPLIANT (18)	NOT COMPLIANT (10)	COMPLIANT
CFSClean3	COMPLIANT	COMPLIANT	COMPLIANT

There are no connections to oss.sonatype.org left. The only remaining entry is Default Deny with a single hit on cdn.functions.azure.com, which is present on dev too and is not a package restore.