Maven Has to Reach the Proxy Plugin Before It Can Run It

An automatic proxy plugin sounds ideal for a laptop that moves between networks. There is one awkward first request: Maven may need the proxy to obtain the plugin itself.

A plugin goal runs only after Maven can resolve and load its implementation and required artifacts. Proxy discovery inside that implementation cannot help a download that fails before the implementation starts. Using fully qualified plugin coordinates can avoid a prefix lookup; it does not make the plugin artifact appear in an empty local repository.

The old Autoproxy Maven plugin illustrates the distinction. Its README describes proxy discovery through proxy-vole, but also describes locally installing the plugin before invoking its goal. Treat that as a prerequisite of that particular design, rather than evidence that Maven universally reads browser PAC settings.

Give the first resolution an explicit route

For a network where repository access requires an HTTP proxy, configure the appropriate active proxy in the Maven settings used by that invocation. For an allowed public-repository bootstrap, choose an HTTP candidate from the HTTP proxy list. An approved internal repository reachable without the external route can also solve the initial access problem. Either approach must cover the plugin and its dependencies, not just the application's dependencies.

A previously populated local repository can conceal the bootstrap requirement. Success on a developer's laptop does not establish that a fresh CI account can start the same build. Look at the failing artifact and phase before changing the plugin's detection logic.

After the plugin loads, a later dependency failure becomes a separate question: whether its detected route is correct and whether the active Maven transport uses the resulting settings. Keep those two failure points distinct when deciding whether automatic detection is worth retaining.