Fork me on GitHub
#tools-deps
<
2022-11-10
>
danm10:11:02

How can I point tools.deps at a different Maven settings.xml? I know it obeys the properties in ~/.m2/settings.xml, but for various reasons I can't use that default path (`${HOME}/.m2/settings.xml`), I need to have my settings file elsewhere. The Internet talks a lot about M2_HOME, but mostly that talk is along the lines of "It's deprecated and causes all sorts of issues, don't use it", and I don't know if tools.deps obeys it anyway

Wanja Hentze10:11:18

and then have .m2/... in that alternative "home directory"

Wanja Hentze10:11:13

I do not know how deprecated/evil this is, I just know it works 😄 Join me in Hyrum's Law-ing it into part of the API

danm10:11:25

Hmm. Can have a go and see if that'll work. Bazel really doesn't like you exposing env vars, but I might be able to set the tool option. Then again, telling it the entirety of it's user.home is somewhere else, rather than just Maven settings, might cause other issues...

Wanja Hentze10:11:14

ah, you're using bazel, neat

danm10:11:30

Ahha, digging into the tools.deps and maven source is giving me a potential route here

Wanja Hentze10:11:36

yes, beating tools.deps into shape for use in hermetic build systems is quite a piece of work 😄

danm10:11:09

I think I can set org.apache.maven.user-settings

danm10:11:37

Because the default settings builder which tools.deps defers to will use that. I think

Wanja Hentze10:11:06

https://imgs.xkcd.com/comics/software_development_2x.png this is how it feels to use tools.deps from Nix (and probably bazel too) 😄

Alex Miller (Clojure team)14:11:16

If you need to set a jvm property on the process that builds the classpath, you can do that by setting env var CLJ_JVM_OPTS (this is preferable to setting JAVA_TOOL_OPTIONS which applies to the user program as well, and also won't spam your stderr)

Carsten Behring13:11:11

Can I exclude "files" (not dependencies) during an uberjar creation ? I have a case were I get an issue because, I get to files copied to 'META-INF", namely mailcap and mailcap.default Removing one manually from the jar solves it. It seems hat this option: :exclude - coll of string patterns (regex) to exclude from deps is for excludings deps only.

Alex Miller (Clojure team)14:11:03

"Use :exclude to exclude specific paths from the expanded deps."

Alex Miller (Clojure team)14:11:28

(also, #C02B5GHQWP4 exists for tools.build questions)

Carsten Behring23:11:02

Thanks. The docu use different wording in 2 places Maybe the Clojuredoc of ubercould be clarified to make it clear that the exclusion is about paths.

FiVo16:11:57

Hey, I am building some uberjar with some dependencies coming from a private artifactory. Building the jar gives me

Execution error (HttpResponseException) at org.eclipse.aether.transport.http.HttpTransporter/handleStatus (HttpTransporter.java:472).
status code: 409, reason phrase: Conflict (409)
and further down in the error report
22    {:type org.eclipse.aether.resolution.ArtifactDescriptorException,
 23     :message
 24     "Failed to read artifact descriptor for io.confluent:kafka-avro-serializer:jar:5.3.2",
 25     :at
 26     [org.apache.maven.repository.internal.DefaultArtifactDescriptorReader
 27      loadPom
 28      "DefaultArtifactDescriptorReader.java"
 29      255]}
I build the same jar with lein just fine. Is tools.deps doing some stricter checking regarding snapshots and releases as this seemed to be a common problem while googling this issue?

FiVo16:11:32

So the same thing happens when try to get a repl via clj and it works fine with lein repl

FiVo16:11:59

$ clj --version
Clojure CLI version 1.11.1.1165
`

Alex Miller (Clojure team)18:11:32

can you provide something more to reproduce? I don't have enough info to comment

Alex Miller (Clojure team)18:11:31

not doing anything special wrt snapshots

Alex Miller (Clojure team)18:11:14

or could you provide more of the exception trace?

uwo16:11:47

I've been having a similar problem -- a tools-deps project can't locate a dependency that my lein projects find fine. I've even used Datomic's bin/maven-install, and I can see that the dependency is available in my local .m2 Clojure CLI version 1.11.1.1200

Alex Miller (Clojure team)17:11:24

Can you share your deps.edn

uwo17:11:32

Sure thing

uwo17:11:33

sorry, let me fix that.. I had reverted to a version of datomic that didn't encounter this issue