I generated a pom for my project using -Spom so I could use dependency-check-maven to find vulnerabilities on dependencies. But since the way maven and tools.deps solve dependencies I got discrepancies on the dependency tree calculated by maven and by clj. Could -Spom return all dependencies including indirect ones or have another command that could do that?

the trees are really different because mvn and clj resolve dependencies differently. which one do you actually care about?

you can grab the actual full set of deps clj is resolving (as data) by looking at the .libs file that's generated

if you do clj -Sverbose you'll see a cp file like .cpcache/723570742.cp - if you replace .cp with .libs, that's the file

that's an edn file, so you could suck it in with clojure and manipulate it however you need

I care about the clojure one, since that will go to production, but the tool to check dependencies uses the pom information.

So reading the .libs file and generating a pom.xml with all dependencies should work.

@alexmiller Does that mean that deps-based projects that use clj -Spom to generate/maintain a pom.xml that is published to Clojars can cause projects that use them to get the "wrong" dependencies?

the generated pom should have only the same top level deps

my understanding of the request above is that he is scanning the full transitive dep tree, which may indeed be different between clj and (mvn or lein)

these differences are presumably mostly same libs but different versions, but in cases where transitive deps change, could be different deps

in theory, that may be an issue. in practice, it seems to rarely matter, perhaps because most libs are subsequently used as someone else's lib, and then lose all control over their dep versions anyways.

Thanks for the clarification!

I have mixed feelings about my experience with the classpath differences today. lein and boot do the same as Maven in resolving transitive dependencies so this is a tools.deps only problem. If -Spom is supposed to create a classpath for libraries it's doing fine with the caveat that if you want to analyze the tools.deps library classpath using the generated pom using Maven tooling you can get results that are not real, but as Alex pointed out, in the end is the application classpath that matters. In the end I think that having an easy way of generating a pom.xml that will create the same classpath as tools.deps is important because of tooling that already exists for Maven.

dependency-check-maven plugin pointed several high/critical vulnerabilities on dependencies used by pedestal and buddy mentioning only libraries that I think are popular in the clojure world. I had no time to check if those could be exploited. This is on the latest release of both libraries. The dependencies have new releases not affected by the vulnerabilities.

my limited experience with dependency-check-maven and the underlying stuff is that the matching is very bad and often highlights libraries that have nothing to do with the CVEs it associates with it

an example is https://github.com/jeremylong/DependencyCheck/issues/1788 which flagged data.zip afaict because it had "zip" in the name and that matched a totally unrelated "zip" project. I dug into the code just enough that I have a really low confidence in the results of this tool. So, fyi.

Having spent a fun afternoon reading cves, looked legit. Cves were very specific on coordinates and versions affected.

if you have a list of issues, would be great if you could just drop it somewhere so we could do necessary stuff to improve things

issues on specific tools would be better, but if you've at least got a list, that would make it faster for someone else to log if you don't have time

on the suggestion re generating a pom, the goal was to create a pom that was similar to the deps.edn, which meant just the top level deps. Stating all lower level deps in the pom would be (conceptually) much different. That's more than I'm planning to take on for -Spom (which itself may get pulled out of tools.deps/clj and put into a standalone tool)

making a tool that used tools.deps and a deps.edn and did the dependency checks directly without involving Maven would be even better

I understand the trade-offs of generating a pom similar to what other tools generate. But that comes with the inconvenience of having different classpaths on different tools because the algorithm used for transitive dependencies is different and the results are different than one would expect. While a tools.deps specific dependency check tool would be indeed better that would mean another tool that someone would have to maintain. Using one that already exists and is maintained has lots of advantages too. I will rerun the analysis without my dependencies overrides and report on each tool tomorrow.

thanks, that would be great

is there a good way to share code between two tools.deps projects living in the same git repo?

@wei use a local dependency when developing them, I think that's what you're asking.

ah thanks for the tip. reading https://clojure.org/guides/deps_and_cli#_using_local_libraries now