Fork me on GitHub
#tools-deps
<
2021-03-19
>
cap10morgan15:03:39

We keep running into issues w/ pom.xml generation / deps-syncing via clojure -Spom combined with pom.xml also being the source of truth for things like project name and version. With tools like make, it's really easy for pom.xml's modified time to be newer than deps.edn's (b/c e.g. you just bumped the version number) but deps.edn still contains newer deps data that needs to be synced over. This seems like an example of the type of problem you run into when you have two sources of truth that need to be kept in sync with each other (or even just one way like it is here). Have other folks run into this? What are people doing to work around it reliably?

cap10morgan15:03:06

I get the impression that there is an aversion to putting something like project version in deps.edn but I wonder if something like a project.edn could make sense and then you generate everything in pom.xml (clobbering the whole file each time) from deps.edn and project.edn (or other similar approach that makes pom.xml just a representation of truth from other sources).

Alex Miller (Clojure team)15:03:09

there is an aversion to doing more on this atm as it's going to be superseded by tools.build and other stuff, hopefully "soon"

cap10morgan15:03:36

ah, cool. that rings a bell now that you mention it. πŸ™‚

seancorfield16:03:26

@cap10morgan Also, if you’re using depstar, you can just say :sync-pom true and it will always update the pom.xml for you. And I tend use :version '"x.y.z"' via depstar too for updating the pom.xml file.

πŸ‘ 3
seancorfield16:03:22

(under the hood, depstar does both the equivalent of clojure -Spom β€” using the same parts of t.d.a. β€” and some other editing so that the SCM tag is also updated when you change the <version> tag)

seancorfield16:03:48

I documented my deployment process for my libraries in the depstar README recently.

dcj18:03:03

@cap10morgan I share your concern about having more than one source of truth in a project. I feel that a pom.xml file ought to be able to be generated dynamically when needed, ideally from the contents of deps.edn and the SCM status of the project. Recent work by @seancorfield on depstar and my (currently unmerged) PR to deps-deploy enable me to specify enough in deps.edn to build a pom.xml dynamically when needed for jar creation and maven deployments. For example, here are the relevant portions of a deps.edn:

:mvn/repos {"acn-snapshots" {:url ""}}

 :deps { ... }

 :aliases
 {:mvn/artifact-id util
  :mvn/group-id    org.aircraft-noise
  :mvn/version     "0.1.4-SNAPSHOT"
  :jar/file-name   "util.jar"

  :jar {:replace-deps
        {com.github.seancorfield/depstar {:mvn/version "2.0.206"}}
        :exec-fn hf.depstar/jar
        :exec-args {:jar         :jar/file-name
                    :artifact-id :mvn/artifact-id
                    :group-id    :mvn/group-id
                    :version     :mvn/version
                    :sync-pom    true}}

  :deploy {:extra-deps {com.dcj/deps-deploy {:mvn/version "2.0.999-SNAPSHOT"}}
           :exec-fn deps-deploy.deps-deploy/deploy
           :exec-args {:installer :remote
                       :sign-releases? false
                       :artifact :jar/file-name
                       :repository "acn-snapshots"}}}
Note that the project version is defined as an alias, and then it is used by depstar to create the pom.xml and jar file.

3
πŸ’― 3
πŸ’‘ 3
dcj20:03:13

Further note that the value of :repository in the :exec-args of the :deploy alias is a string, which is used to find the actual respository location from the :mvn/repos map elsewhere in deps.edn, and then the credentials for that repo are obtained via ~/.m2/settings.xml