Skip to content
This repository has been archived by the owner on Feb 24, 2023. It is now read-only.

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

Closed
pmonks opened this issue Jul 26, 2022 · 4 comments
Closed

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

pmonks opened this issue Jul 26, 2022 · 4 comments

Comments

@pmonks
Copy link

pmonks commented Jul 26, 2022

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.

@seancorfield
Copy link
Owner

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.

pmonks added a commit to pmonks/pbr that referenced this issue Jul 26, 2022
@pmonks
Copy link
Author

pmonks commented Jul 26, 2022

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.

@seancorfield
Copy link
Owner

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.

@pmonks
Copy link
Author

pmonks commented Jul 26, 2022

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants