Thanks again for your advice, I ended up using clojure -Spom to create a pom as a source of truth for the group-id/artifact-id/version, and then configured deps.edn to be

:depstar {:replace-deps {seancorfield/depstar {:mvn/version "2.0.188"}}
          :ns-default hf.depstar
          :exec-args {:jar "app.jar"
                      :sync-pom true}}
:deploy {:extra-deps {slipset/deps-deploy {:mvn/version "RELEASE"}}
         :exec-fn    deps-deploy.deps-deploy/deploy
         :exec-args  {:installer :remote
                      :sign-releases? false
                      :artifact "app.jar"}}

@tomjkidd If you create a new project with clj-new, it has a fully-flesh-out pom.xml file. What clojure -Spom generates is too minimal to use with, say, http://cljdoc.org

FYI:

seanc@DESKTOP-30ICA76:~/clojure$ clojure -X:new :template app :name seancorfield/my-example
Generating a project called my-example based on the 'app' template.
seanc@DESKTOP-30ICA76:~/clojure$ cat my-example/deps.edn
{:paths ["src" "resources"]
 :deps {org.clojure/clojure {:mvn/version "1.10.2"}}
 :aliases
 {:run-m {:main-opts ["-m" "seancorfield.my-example"]}
  :run-x {:ns-default seancorfield.my-example
          :exec-fn greet
          :exec-args {:name "Clojure"}}
  :test {:extra-paths ["test"]
         :extra-deps {org.clojure/test.check {:mvn/version "1.1.0"}}}
  :runner
  {:extra-deps {com.cognitect/test-runner
                {:git/url ""
                 :sha "b6b3193fcc42659d7e46ecd1884a228993441182"}}
   :main-opts ["-m" "cognitect.test-runner"
               "-d" "test"]}
  :uberjar {:replace-deps {seancorfield/depstar {:mvn/version "2.0.171"}}
            :exec-fn hf.depstar/uberjar
            :exec-args {:aot true
                        :jar "my-example.jar"
                        :main-class "seancorfield.my-example"
                        :sync-pom true}}}}
seanc@DESKTOP-30ICA76:~/clojure$ cat my-example/pom.xml
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="" xmlns:xsi="" xsi:schemaLocation=" ">
  <modelVersion>4.0.0</modelVersion>
  <groupId>seancorfield</groupId>
  <artifactId>my-example</artifactId>
  <version>0.1.0-SNAPSHOT</version>
  <name>seancorfield/my-example</name>
  <description>FIXME: my new application.</description>
  <url></url>
  <licenses>
    <license>
      <name>Eclipse Public License</name>
      <url></url>
    </license>
  </licenses>
  <developers>
    <developer>
      <name>Seanc</name>
    </developer>
  </developers>
  <scm>
    <url></url>
    <connection>scm:git:>
    <developerConnection>scm:git:>
    <tag>HEAD</tag>
  </scm>
  <dependencies>
    <dependency>
      <groupId>org.clojure</groupId>
      <artifactId>clojure</artifactId>
      <version>1.10.1</version>
    </dependency>
  </dependencies>
  <build>
    <sourceDirectory>src</sourceDirectory>
  </build>
  <repositories>
    <repository>
      <id>clojars</id>
      <url></url>
    </repository>
    <repository>
      <id>sonatype</id>
      <url></url>
    </repository>
  </repositories>
  <distributionManagement>
    <repository>
      <id>clojars</id>
      <name>Clojars repository</name>
      <url></url>
    </repository>
  </distributionManagement>
</project>

This has all the SCM information etc that http://cljdoc.org is going to look for.

(I really should change the template so the <tag> matches the version)

Github packages seems a bit less strict, and thanks for more information!

One last hiccup I was curious if you had info on. In prod, we use JDK 11, and locally I had a JDK 15 installation, does jar creation respect maven properties in a pom.xml that would control the source/target?

<properties>
       <maven.compiler.source>11</maven.compiler.source>
       <maven.compiler.target>11</maven.compiler.target>
  </properties>

I had been using the following to figure out the

unzip -p app.jar META-INF/MANIFEST.MF
Manifest-Version: 1.0
Created-By: depstar
Built-By: tomjkidd
Build-Jdk: 11.0.4

I realize now that even though Build-Jdk is set that way, it is possible that class files correspond to a different version

@tomjkidd Right, I was about to link to the source in depstar that builds that. pom.properties is created here: https://github.com/seancorfield/depstar/blob/develop/src/hf/depstar/uberjar.clj#L443-L449

And the MANIFEST.MF file here: https://github.com/seancorfield/depstar/blob/develop/src/hf/depstar/uberjar.clj#L398-L410

Only GAV (group, artifact, version) come from the pom.xml file.

Alright, so source/target control is out-of-scope of that tool then

Thanks, again

(and sorry if you’ve answered these questions before, I tried to research as much as I could before asking more)

Is it correct to say that due to the construction process, IE ProcessBuilder and the use of compile, that it is safe to assume that the Build-Jdk is the same as the class version would be?

I think the answer to that is "There is currently no way to tell depstar to use a different JVM to run the compilation process" -- but the Build-Jdk is discovered from the JVM that runs depstar.

In other words, there's an assumption that the JDKs are the same, and I hadn't thought about the possibility that the JDK used to run the compilation process might be different to the JDK used to run depstar itself... An interesting question.