You shouldn't actually try to override the file - Share supports loading multiple views and you could simply load a custom client side JavaScript file as a separate view mode using clean extension points, without overriding that file.
On the nature of "why this doesn't work with SDK 3.0" though I don't know - I neither use SDK 3.0 nor ever try to override any of the default files. One thing to note though is that when you are using the JAR archetype you should - by default - be producing a JAR artifact. JAR artifacts are not installed into the Share WAR like AMPs are - the file-mapping.properties does not have any effect for them. For JARs, the only way to "override" (not really an override, simply just a trickery played by (potentially unreliable) classpath load order precedence) is by packaging the resource inside the the JAR via src/main/resources. One potential issue I could imagine only affects production use cases, especially if you do not include a minified version of the file - in that case, the minified version of the original WAR would take precedence and your "override" would be ignored.
