For one thing, GIT and Subversion can have different SCM URIs for read-write and read-only access.
This is what the different <connection>
and <developerConnection>
URIs are supposed to capture. The first is a URI that is guaranteed read access. The second is a URI that is guaranteed write access.
Very often from a checked out repository, it is not possible to infer the canonical URIs.
For example, I might check out the Subversion repository in-house via the svn:
protocol and the IP address of the server, but external contributors would need to use https://
with the hostname.
Or even with GIT repositories, on Github you have different URIs for different access mechanisms, e.g.
https://github.com/stephenc/eaio-uuid.git
(read-write using Username / Password or OAuth)
git@github.com:stephenc/eaio-uuid.git
(read-write using SSH private key Identification)
git://github.com/stephenc/eaio-uuid.git
(anonymous read only)
Never mind that you may have checked out git://github.com/zznate/eaio-uuid.git
or cloned a local check out, in other words, your local git repository may thing that "upstream" is ../eaio-uuid-from-nate
and not git@github.com:stephenc/eaio-uuid.git
I agree that for some SCM tools, you could auto-detect... for example if you know the source is checked out from, e.g. AccuRev, you should be OK assuming its details... until you hit the Subversion or GIT or CVS or etc code module checked out into the AccuRev workspace (true story) so that the tag that was being pulled in could be updated.
So in short, the detection code would have to be damn sure that you were not using two SCM systems at the same time to be sure which is the master SCM... and the other SCM may not even be leaving marker files on disk to sniff out (AccuRev, for example, doesn't... hence why I've picked on it)
The only safe way is to require the pom to define, at least the SCM system, and for those SCM systems where the URI cannot be reliably inferred (think CVS, Subversion, GIT, HG, in fact most of them) require the URI to be specified.