@drewverlee maybe obvious but worth noting, if you control the repo you can just lein pom and check in the pom.xml next to the project.clj

I'm starting to feel that both lein pom and clj -Spom is a case of easy over simple. There is a dependency format — pom, that has many different stuff in it. It's much more than list of deps + artifact + version, but tools like lein pom and clj -Spom give only the most common baseline, which might cover some percentage of use cases, but whenever I want to publish a library, I realize that that's not enough. I need to specify developer/license information. I need to specify version as tag in scm information. Someone else will want to specify git sha instead of tag in scm. Dependencies I use during development might go to different profiles, with different activation rules, so what lein/`clj` provides to update dependency list might even be wrong. I guess ideally I want to produce pom from code I write, aided with information from tools-deps/git and some helpers to generate xml from data, but ultimately be the one who decides what goes where. I guess where is no such tool yet because you can just check in pom.xml and update it with scripts using sed or whatever, and that's good enough.

Using sed for xml was hard :) Garamond works okay in this space.

I think it's okay to say that pom.xml is a combination of data sources into one. I personally would not want to manage the tag/version stuff as I'd definitely get it wrong.

Interesting. So assuming no plugin modifies the deps. then its as easy as generating a pom for say a project like: https://github.com/weavejester/integrant?

Yup

Although a deps.edn is probably easier

what would the output of clj -Spath | grep integrant containing integrant twice imply? Im trying to undertsand a build error. /home/drewv/.gitlibs/libs/integrant/integrant/c673b85130e553feec6d4c5d2d1ec773a49c929c/src:/home/drewv/.gitlibs/libs/integrant/integrant/c673b85130e553feec6d4c5d2d1ec773a49c929c/src/main/clojure

it doesn't contain integrant twice

it contains two source directories from within integrant (src and src/main/clojure)

the latter doesn't exist, so no worries

(that's the standard Maven source path for Clojure source files)

thanks alex. So {:warning "could not find classpath entry", :path "/home/drewv/.gitlibs/libs/integrant/integrant/c673b85130e553feec6d4c5d2d1ec773a49c929c/src/main/clojure"} isn't indicating something is wrong with my build? its because ____ produces that path and then a later tool can't find the entry on it?

I don't know what that is

where do you see it?

it's certainly not an issue to the jvm to have a classpath entry that doesn't exist

which I assume is why that's a warning

thats the output from running depstar https://clojars.org/seancorfield/depstar. Right, makes sense. thanks

@drewverlee Integrant doesn't have a deps.edn file and that path indicates you are depending on it via a :git/url?

It's a fork.

Ah, with a pom.xml file. Got it.

@alexmiller Does t.d.a. assume src/main/clojure when it sees a POM file in a Git dep?

hello! I am wondering, should :override-deps affect the pom.xml generated/updated by -Spom?

@lee If you specify an alias that brings in that override...

(at least, that's why I would expect -- I've never tried it)

Yep, I am specifying the alias and it does not affect pom.xml in my little test. Could be I botched something.

Based on a quick test, it doesn't seem to.

(! 815)-> cat deps.edn 
{:paths ["resources" "src"]
 :deps {org.clojure/clojure {:mvn/version "1.10.1"}}
 :aliases
 {:test {:extra-paths ["test"]
         :extra-deps {org.clojure/test.check {:mvn/version "0.10.0"}}}
  :old {:override-deps {org.clojure/clojure {:mvn/version "1.9.0"}}}
  :runner
  {:extra-deps {com.cognitect/test-runner
                {:git/url ""
                 :sha "76568540e7f40268ad2b646110f237a60295fa3c"}}
   :main-opts ["-m" "cognitect.test-runner"
               "-d" "test"]}}}

Fri Nov 08 11:33:00
(sean)-(jobs:0)-(~/clojure/pommy.example)
(! 816)-> clj -A:old
Clojure 1.9.0
user=> ^D

But clj -A:old -Spom produces a pom.xml that uses 1.10.1 not 1.9.0

thanks sean! -Stree behaves as expected:

> clj -A:old -Stree
org.clojure/clojure 1.9.0
  org.clojure/spec.alpha 0.1.143
  org.clojure/core.specs.alpha 0.1.24

I'd say that's a bug. @alexmiller?

this is trickier than it looks. I may actually have broken it in my recent set of changes. the tricky part is that the aliases are about resolving transitive deps and building a classpath, but you're not actually building a classpath here, you're just making a different manifest file

so if you supplied override-deps for some lib N levels down, what does that mean? do you add it to the root deps to get the same effect? or just ignore it?

I would certainly expect the dependencies in pom.xml to match the top-level deps in -Stree output but I agree that it's really hard to decide what the transitive dependencies should be. Hmm :thinking_face:

I used to do a bunch of fiddly logic to half apply stuff from the aliases during gen, but I stopped doing that in my last round of changes and just reused the same core from making classpaths, but did not properly take that all the way

Forgive my naive question @alexmiller, I'm sure you've put much thought into this. Wouldn't adding the override of the transitive dep to the root deps give the intended result?

Also do you want me to raise an issue for this? Or is it via ask clojure now?

I've actually fixed it locally, so no need to do anything. I'll probably log a jira just for tracking before I commit it

on the transitive deps, the decision I had made in the past was to only modify the root deps and not include overrides in transitive deps

and that's what I'm matching in the update. inevitably, all decisions here will be wrong for someone.

true enough! So long as behavior is consistent and easy to understand, it works for me! (for what that's worth!)

@lee https://clojure.atlassian.net/projects/TDEPS/issues/TDEPS-143, fix in master but not released

cool, thanks alex!