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?
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).
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"
ah, cool. that rings a bell now that you mention it. π
@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.
(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)
I documented my deployment process for my libraries in the depstar
README recently.
@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 "<https://repo.deps.co/aircraft-noise/snapshots>"}}
: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.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