<scm><tag> value in pom.xml is overwritten with incorrect value

[pmonks]

I have a project that publishes artifacts to Clojars, and those artifacts include a pom.xml file that (amongst other things) contains this element:

<scm>
  <url>https://github.com/pmonks/clj-wcwidth</url>
  <connection>scm:git:git://github.com/pmonks/clj-wcwidth.git</connection>
  <developerConnection>scm:git:ssh://git@github.com/pmonks/clj-wcwidth.git</developerConnection>
  <tag>1.0.64</tag>
</scm>

However after deployment, the pom.xml file hosted by Clojars contains this element instead:

<scm>
  <url>https://github.com/pmonks/clj-wcwidth</url>
  <connection>scm:git:git://github.com/pmonks/clj-wcwidth.git</connection>
  <developerConnection>scm:git:ssh://git@github.com/pmonks/clj-wcwidth.git</developerConnection>
  <tag>v1.0.64</tag>
</scm>

Note the letter 'v' added as a suffix to the value of the <tag> nested element.

This value is invalid, as there is no tag v1.0.64 in the source repository, and this causes some downstream tooling to fail. There is a 1.0.64 tag in that repository however, so if the original value that was deployed had been preserved, the downstream tooling would function as expected.

Is there a way to tell Clojars not to mess with any values that I provide in the pom.xml I deploy to it? I'm comfortable for Clojars to augment the data that's there with anything that's missing that Clojars considers mandatory, but overwriting data that I provide seems quite problematic, especially (as in this case) when the Clojars-generated value is invalid.

[tobias]

Is there a way to tell Clojars not to mess with any values that I provide in the pom.xml I deploy to it? I'm comfortable for Clojars to augment the data that's there with anything that's missing that Clojars considers mandatory, but overwriting data that I provide seems quite problematic, especially (as in this case) when the Clojars-generated value is invalid.

Hi @pmonks! Clojars does not do any rewriting of the pom on deploy (or ever); the pom that your deploy client sends is the one we use. So you will need to look at your build tooling.

Looking at the pom.xml that was embedded in the deployed jar, the pom file in it (under META-INF/maven/com.github.pmonks/clj-wcwidth/pom.xml) also has the v-prefixed tag, so your tooling is generating the pom before building the jar (if that helps track it down).

On Mon, Jul 25, 2022, at 21:57, Peter Monks wrote:

I have a project https://github.com/pmonks/clj-wcwidth/ that publishes artifacts to Clojars, and those artifacts include a pom.xml file that (amongst other things) contains this element:

https://github.com/pmonks/clj-wcwidth scm:git:git://github.com/pmonks/clj-wcwidth.git ***@***.***/pmonks/clj-wcwidth.git 1.0.64

However after deployment, the pom.xml file hosted by Clojars https://repo.clojars.org/com/github/pmonks/clj-wcwidth/1.0.64/clj-wcwidth-1.0.64.pom contains this element instead:

https://github.com/pmonks/clj-wcwidth scm:git:git://github.com/pmonks/clj-wcwidth.git ***@***.***/pmonks/clj-wcwidth.git v1.0.64

Note the letter 'v' added as a suffix to the value of the <tag> nested element.

This value is invalid, as there is no tag v1.0.64 in the source repository https://github.com/pmonks/clj-wcwidth/tree/v1.0.64, and this causes some downstream tooling to fail https://cljdoc.org/builds/59944. There is a 1.0.64 tag in that repository however https://github.com/pmonks/clj-wcwidth/tree/1.0.64, so if the original value that was deployed had been preserved, the downstream tooling would function as expected.

Is there a way to tell Clojars not to mess with any values that I provide in the pom.xml I deploy to it? I'm comfortable for Clojars to augment the data that's there with anything that's missing that Clojars considers mandatory, but overwriting data that I provide seems quite problematic, especially (as in this case) when the Clojars-generated value is invalid.

— Reply to this email directly, view it on GitHub https://github.com/clojars/clojars-web/issues/841, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAAUR3TXEE23P2LHYHQMLTVV5AY5ANCNFSM54UHPZIQ. You are receiving this because you are subscribed to this thread.Message ID: @.***>

[pmonks]

Thanks @tobias! I'm at quite a loss then, as another project I checked (not written by me, but one that I've used in some other projects of mine) also has some strange <scm><tag> rewriting going on, and it uses a completely different set of build & deploy tools to what I'm using (I use tools.build+deps-deploy, that project uses Leiningen). I double checked with the author of that project, and he doesn't know how that element got in his pom.xml either.

But if it's not Clojars, the only other possibility I can think of is that both tools.build/deps-deploy and Leiningen use some shared underlying code for building and/or deploying pom.xml files, and it's that code that's erroneously modifying the <scm><tag> value.

[danielcompton]

Not sure if it helps but the v prefix sounds likes the default behaviour of lein release.

[pmonks]

Thanks @danielcompton! Yeah my project (which I have more visibility into / control over, obvs) uses tools.build+deps-deploy, so in theory Leiningen shouldn't be a factor. But perhaps deps-deploy uses some of the same code as lein release?

My current lines of investigation:

1. try to figure out where META-INF/maven/com.github.pmonks/clj-wcwidth/pom.xml comes from, and why it isn't simply a verbatim copy of ./pom.xml
2. try to figure out whether deps-deploy reuses any Leiningen code

[pmonks]

It gets weirder and weirder...

[pmonks]

Ok I think I've found the root cause of the problem. I'll raise an issue against build-clj.