Site builds rely on HTTP 404

If the pom.xml that is being built has a parent that is stored in a remote repository, then the site plugin (or some other part of the site-building process) will try to find two files alongside the parent pom - site_en.xml and site.xml.

Since these files are being fetched from a remote repository, there is the potential for network issues, and I've seen cases where builds fail semi-randomly as well as consistently. The key problem seems to be that the child build relies on getting 404 for both files from the remote repository before it can continue. This can be a bigger problem if there are multiple remote repositories, as all repositories must return 404 for both files before the child build can continue.

The Maven recommendation is to use site:attach-descriptor in the parent build to publish site.xml in cases like this. However, this is insufficient, as site:attach-descriptor only publishes site.xml and not site_en.xml, so the client build still relies on getting 404 on site_en.xml in order to be able to continue.

As per this answer, there is a hacky workaround to allow both site_en.xml and site.xml to be published from the parent project by mis-using the locales configuration. Once both files are published, the client build no longer needs to rely on HTTP 404 as it finds both files it is looking for.

Given how everything works today, I suspect that the client build is going to have to continue to use HTTP 404, as making it more tolerant could mask errors. Unless there is some way to provide a config flag in the site plugin of the child build.

I suspect that the only way to tackle this issue will be to make site:attach-descriptor publish both site_en.xml and site.xml by default (without the need for hacky locales config).

See also MSITE-639 which provides more info.