5

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?

Duncan Jones
  • 67,400
  • 29
  • 193
  • 254
Marc Swingler
  • 181
  • 10

1 Answers1

4

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.

Stephen Connolly
  • 13,872
  • 6
  • 41
  • 63
  • Thanks Stephen, I can see now that reliance on info from the local repo definitely wouldn't work as a default. But aren't most folks running the release plugin doing so from a CI environment against one particular repository/URI? Every CI job I have points to a "canonical" repo where builds for a particular project come from. Seems like it'd be a nice option to have even if turned off by default. – Marc Swingler Feb 04 '13 at 14:47
  • Well at CloudBees our release jobs can end up pointing to one of 4 canonical repositories for our internal code base... and given that we provide CI as a service I suspect that most folks are not in the situation you describe... in fact most of our customers that I have provided support for are not in this situation. You must be lucky ;-). Also keep in mind that GIT repos are very granular, so if you use GIT the situation you describe will *never* happen for the 99% – Stephen Connolly Feb 04 '13 at 16:02
  • I guess I must be lucky. Every CI job I have, and I have dozens, points to a single canonical repository. Know of any articles/blogs that go into greater depth for the setup you describe? Who knows, maybe I'll find a pattern I'll like better than I'm using now. And thanks again for the comments. – Marc Swingler Feb 04 '13 at 16:43