seancorfield / build-clj

Common build tasks abstracted into a library.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

<scm><tag> value overwritten with invalid tag value

pmonks opened this issue · comments

This is two interrelated issues:

First, when a source pom.xml exists, and the <scm><tag> element in it already has a value, build-clj unconditionally overwrites the value of that element in the duplicate pom.xml file that is written to META-INF when the existing value from the source pom.xml should be preserved instead. Yes (:tag opts) can be used to override this behaviour, but it is reasonable to expect that build-clj would preserve all values found in the source pom.xml, without needing to be told to do so elsewhere.

Second, even in the case where that element doesn't exist in the source pom.xml file, build-clj assumes GitHub tags of the form "v(:version opts)", which is not guaranteed to be a valid tag in the source GitHub repo. In fact many GitHub repos label tags with raw version numbers without any prefix, and this then causes problems for downstream tools that use the value of the <scm><tag> element for their own processing, for example cljdoc.

See also this Clojars issue, where this issue was initially discussed.

If you don't want the defaults that build-clj provides -- because it assumes a minimal or non-existent pom.xml template -- then use tools.build directly instead.

If you specify :tag, build-clj uses that instead of setting <tag> to v(:version opts) -- again, if you don't want these defaults, either override them or use tools.build directly.

You're a power user who wants different defaults -- you are not the target user for build-clj.

Might I suggest an update to the build-clj documentation then, to make it clear that pom.xml is not, in fact, a "template"?

The behaviour you're describing for build-clj's handling of pom.xml files does not meet any generally accepted definition of the word "template" that I've ever heard, and will catch other users of build-clj off guard when they discover that "power user" values they've placed in their pom.xml "template" get unexpectedly overwritten.

Feel free to submit a documentation PR but you're the only person who has been caught out by the behavior so far - because you're not the target user for this library.

Thanks, but if I'm "not the target user for this library" I'm disinclined to contribute to it any further than I already have.