Clojurians Log v2

having thought it about it some, I'm not interested in a patch to "fix" this in this way as the behavior here is intentional - the basis is intended to build the classpath, which consists of jars and paths, not zip aar etc

but it would be interesting to provide additional apis to resolve non-jar artifacts. that capability exists at lower levels but is pretty obscure to use.

I would be interested to learn more about the real use case here (because I presume it is not classpath building). why are these artifacts not jar files? how do you use them? why are they included as deps? are they for native libraries?

Thanks for considering this, Alex! Here are two real-world use cases I’ve encountered: 1. NewRelic APM (Java agent) NewRelic APM consists of two parts: • SDK*(`newrelic-api`) — a regular classpath dependency • Java agent (`newrelic-agent`) — a jar that lives outside the classpath, passed via -javaagent:newrelic.jar Currently I have to specify the version twice: once in deps.edn for the API, and separately download the agent jar. I’d love to declare the version once and have build.clj produce both app.jar and newrelic.jar in ./target. Also NewRelic publishes a zip artifact containing both jars plus configs: https://mvnrepository.com/artifact/com.newrelic.agent.java/newrelic-java/9.0.0 Being able to resolve this zip would let me keep version in one place. 2. AAR artifacts (Android libraries) I needed to run the NewRelic Android agent in a regular JVM (not on device/emulator) for demo and load testing — spinning up hundreds of agents with minimal memory footprint. The agent is distributed as AAR, which is essentially a zip containing classes.jar that I extract and reference via :local/root. * In both cases, no native libraries are involved (or they’re irrelevant to my use). What I’d ideally want is something like:

{:deps {...} 
 :artifacts {com.newrelic.agent.java/newrelic-java {:mvn/version "9.0.0" :extension "zip"}}}