Home/ Questions/Q 9250857
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-18T10:32:58+00:00

As far as I am aware, in order to use the maven-release-plugin, you have

  • 0

As far as I am aware, in order to use the maven-release-plugin, you have to drop in an scm section into your POM file. E.g.:

<scm>
    <connection>scm:hg:ssh://hg@bitbucket.org/my_account/my_project</connection>
    <developerConnection>scm:hg:ssh://hg@bitbucket.org/my_account/my_project</developerConnection>
    <url>ssh://hg@bitbucket.org/my_account/my_project</url>
    <tag>HEAD</tag>
</scm>

I understand this data is used to determine what to tag and where to push changes. But isn’t this information already available if you have the code cloned/checked-out? I’m struggling a bit with the concept that I need to tell maven what code it needs to tag when it could, at least in theory, just ask Git/HG/SVN/CVS what code it’s dealing with. I suspect I’m missing something in the details, but I’m not sure what. Could the the maven-release-plugin code be changed to remove this as a requirement, or at least make auto-detection the default? If not could someone provide some context on why that wouldn’t work?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0