@tomjkidd has joined the channel
Is there a way to configure depstar and deps-deploy so that build/deploy can share a configured semantic version?
I have something like the following, but I’d like to make it so that it is controlled with a version configuration, if possible (instead of having to update the version and jar references)
{:deps {org.clojure/clojure {:mvn/version "1.10.1"}
org.clojure/java.classpath {:mvn/version "1.0.0"}
org.clojure/tools.logging {:mvn/version "1.1.0"}
org.clojure/tools.namespace {:mvn/version "1.1.0"}}
:paths ["src"]
:aliases
{:test
{:extra-paths ["test"]
:extra-deps {lambdaisland/kaocha {:mvn/version "1.0.732"}}
:main-opts ["-m" "kaocha.runner"]}
;; Build jar
;; clojure -X:depstar jar :verbose true :repro true
:depstar
{:replace-deps {seancorfield/depstar {:mvn/version "2.0.188"}}
:ns-default hf.depstar
:exec-args {:group-id group
:artifact-id artifact
:version "0.1.0"
:jar "app-0.1.0.jar"
:sync-pom true}}
;; Deploy to Github packages
;; NOTE Set CLOJARS_URL CLOJARS_USERNAME and CLOJARS_PASSWORD first!
;; clojure -X:deploy
: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-0.1.0.jar"}}}}
@tomjkidd Alex Miller said just the other day that pom.xml should be considered the "source of truth" for version information -- and for build/deploy to Clojars, I just use generic JAR names without a version (the name is irrelevant because the group / artifact / version determines what it ends up being called on Clojars).
When I'm getting ready to make a release -- at the point I updated all doc references to the new version -- I run clojure -X:jar :version '"the.new.version"' and it updates the version (and SCM tag) in pom.xml and I commit that and all the doc changes together, push to GH, cut a release with its release notes on GH, pull just to get that tag locally, then clojure -X:deploy
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.4I 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.
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"}}
The other -X:jar and -X:deploy commands then worked as expected.@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)
Awesome, thanks for the information!
The version is not in my deps.edn file.
See the deps.edn files in depstar, clj-new, next.jdbc etc...
I didn't know I could leave those things unset
https://github.com/seancorfield/depstar/blob/develop/deps.edn#L15-L19
There's a #depstar channel if you have Qs about depstar BTW.
I'm taking on some work for lein and deps.edn projects to deploy to github packages, so I got into a working state, and the dust is just settling. I'll try to read through this to understand better. Thank you for your time and work!