In one of our company's projects, shade tries to resolve using the repositories defined in the module's parent:
(Yep, the JBoss one is out of date.) It doesn't consult settings.xml, though. Also, the parent POM it's trying to find is already in ~/.m2/repository. Our workaround is to put our company repository in that section, which makes sense anyway. Running it once with the workaround caused the parent POM to be downloaded AGAIN. Subsequent times, the POM was NOT redownloaded. Also, if you have a repository manager like Nexus configured on your machine as a mirror for *, this avoids the problem. Oddly enough, the problem didn't happen on Jenkins even though neither of these workarounds was present.
Actually, now that I think about it, is this by design? This is producing an artifact, the dependency-reduced POM, and its contents should be predictable, not dependent on what a particular developer has in her settings.xml...