[integrations][azureai] Remove the deprecated Azure AI Inference integration

[weiqingy]

Linked issue: #931

Purpose of change

integrations/chat-models/azureai is built on com.azure:azure-ai-inference, which Microsoft has deprecated and retires on 2026-08-26. Past that date the integration sits on a dependency that no longer receives fixes, including security fixes.

This removes the module outright rather than shipping a deprecated compatibility layer, per the direction settled on the issue.

The replacement is OpenAICompletionsConnection pointed at a Microsoft Foundry OpenAI v1 endpoint. The two are close enough to make the compatibility layer unnecessary: the Azure OpenAI endpoint also serves non-OpenAI models, and the Cohere, Llama, Mistral and Phi families this module was documented for are sold by Azure on that same resource (endpoints doc).

The migration note in chat_models.md carries the parameter mapping. Two points worth surfacing here because they are the ones that bite:

The endpoint value changes shape, not just its key name. https://<resource>.services.ai.azure.com/models becomes https://<resource>.openai.azure.com/openai/v1/. Carrying the old value into api_base_url unchanged will not work.

model must be set explicitly to the Foundry deployment name. It is not enforced as required: OpenAICompletionsSetup substitutes gpt-4o-mini when it is blank, so omitting it fails provider-side against Foundry rather than at config time.

The note also explains why the target is OpenAICompletionsConnection rather than AzureOpenAIChatModelConnection, since only one of the two has "Azure" in its name: the /openai/v1/ route uses implicit versioning and takes no api-version, which AzureOpenAIChatModelConnection requires.

The azure YAML alias is removed rather than repointed. azure_openai already resolves to the Java Azure OpenAI classes in both languages, so no provider becomes unreachable by alias.

A dependency version change rides along with this removal

Worth calling out explicitly, since it is not obvious from a removal diff.

azure-core was mediating mcp-core's declared reactor-core:3.7.0 down to 3.4.41. Deleting the module removes that pin, so the shaded distribution jar now bundles 3.7.0, and the bundled NOTICE is updated to match.

No dependencyManagement entry was added to hold 3.4.41. That version was an artifact of dependency mediation rather than a deliberate choice, so pinning it back would re-freeze an accident and keep mcp-core on an older reactor than it asks for. Happy to be redirected if the project would rather pin.

The second commit updates META-INF/NOTICE and drops four now-orphaned license texts. Each of the 46 removed entries was checked by locating that artifact's own jar and testing whether any of its entries survive in the rebuilt shaded jar, rather than by matching on the coordinate prefix. That distinction matters here: the azure block is interleaved with entries that must stay, so reactive-streams and reactor-core remain bundled through other paths while jna and jna-platform drop out entirely. Entries carrying no distinguishing payload were kept, since over-listing is the safer error.

The two commits are ordered removal-then-NOTICE deliberately. The reverse would briefly describe a jar that still bundles the module with a NOTICE missing 46 entries and four license texts covering still-shipping dependencies.

Tests

No new tests. This removes code and its wiring; there is no new behavior to pin.

Verified on the branch: tools/build.sh clean, tools/ut.sh green (Java 0 failures and 0 errors across modules, Python 812 passed and 13 skipped), tools/lint.sh -c clean, tools/check-license.sh clean. The rebuilt distribution jar was checked to ship the corrected NOTICE.

ChatModelIntegrationAgent and ChatModelIntegrationTest referenced the removed constants, so the tree does not compile without editing them. Their AZURE provider branch was deleted rather than repointed at a Foundry endpoint, which would have meant inventing an unspecified credential-gated configuration. No workflow or script references AZURE_ENDPOINT or AZURE_API_KEY.

Two gaps I have not closed, stated plainly rather than left implied. The e2e suite was not run, since it needs Ollama and credentials; the two edited e2e files are verified to test-compile only. And no Hugo render was performed, so the doc anchors were checked by reading headings rather than by rendering the site.

API

Yes. This removes public API.

Removed: AzureAIChatModelConnection and AzureAIChatModelSetup; ResourceName.ChatModel.AZURE_CONNECTION and AZURE_SETUP on the Java side and their ResourceName.ChatModel.Java.* counterparts on the Python side, which is how Python agents reached the module cross-language; the azure YAML alias for both chat_model_connections and chat_model_setups; and the flink-agents-integrations-chat-models-azureai Maven artifact.

An existing clazz: azure in YAML now fails at class load naming the missing class, rather than reporting an unknown alias, because Aliases.resolveClazz passes unrecognized names through unchanged. That pass-through behavior is unchanged by this PR, and the migration note covers the rename for YAML users as well as for the Java API.

Documentation

• doc-needed
• doc-not-needed
• doc-included

Was this patch authored or co-authored using generative AI tooling?

• Yes
• No

Generated-by: Claude Code 2.1.226, included in both commit messages.

[wenjin272]

One documentation clarification:

[wenjin272]

The statement that gpt-4o-mini "does not exist on a Foundry resource" is too absolute. With the OpenAI v1 API, model is the deployment name, and a deployment may legitimately be named gpt-4o-mini. If no such deployment exists, the request fails later at the provider; if one does exist, omitting model may silently select an unintended deployment. Could we instead say that the default may not match the intended deployment and therefore model should be set explicitly?

[weiqingy]

You're right, that was overreaching.

Reworded to cover both outcomes:

Set model explicitly to your Foundry deployment name. Leaving it out is not reported as a configuration error: OpenAICompletionsSetup substitutes its own OpenAI default (gpt-4o-mini), and on the OpenAI v1 route that value is read as a deployment name. If no deployment on the resource carries that name, the request fails later at the provider; if one does, it is used silently in place of the deployment you meant.

I kept both branches rather than the shorter "may not match the intended deployment", since the silent-selection case is the expensive one to debug.

[weiqingy]

Rebased onto main to clear the conflict with #991.

Worth flagging, since it is not obvious from the diff: the rebase also drops the five netty-tcnative-boringssl-static per-platform rows #991 added. They arrive under azure-core-http-netty, which declares the bare tcnative artifact, and that artifact declares the five per-platform jars itself. With the module gone, nothing pulls tcnative any more. netty-handler still ships but declares it optional, so netty falls back to its JDK SSL provider, as it does on any classpath without the native library.