@seancorfield I just tried it, and it didn't work. My deps.edn-fu is weak, and maybe I didn't follow your docs correctly, here is a snippet from my deps.edn:
:aliases
{
:artifact-id ["util"]
:group-id ["org.aircraft-noise"]
:version ["0.1.4-SNAPSHOT"]
:jar {:replace-deps
{com.github.seancorfield/depstar ; 2.0.next:
{:git/url "<https://github.com/seancorfield/depstar>"
:sha "a8cf78c9e09e3504e64fc77bcb133a7ada39a68f"}}
:exec-fn hf.depstar/jar
:exec-args {:jar "util.jar"
:artifact-id :artifact-id
:group-id :group-id
:version :version
:sync-pom true}}}
the resulting pom.xml contains the literal keyword values eg.
<groupId>:group-id</groupId>
<artifactId>:artifact-id</artifactId>
<packaging>jar</packaging>
<version>:version</version>
changing the alias keywords to e.g. :artifact/id
did not help
@dcj Did you use -X:jar
as the alias for running depstar
?
Also the three aliases you have are vectors -- but those are not legal values for those exec args.
:artifact-id util
:group-id org.aircraft-noise
:version "0.1.4-SNAPSHOT"
^ Those are validHmm, yeah, something isn't right with that... let me debug...
My bug. It worked for some options but not for all of them. Fixed now! See the new SHA here:
(! 821)-> clojure -Sforce -X:jar
Cloning: <https://github.com/seancorfield/depstar>
Checking out: <https://github.com/seancorfield/depstar> at ee2badaaf4b26754f903ed92e77fd4e82cf2ed70
[main] INFO hf.depstar.uberjar - Synchronizing pom.xml
Skipping paths: resources
[main] INFO hf.depstar.uberjar - Building thin jar: util.jar
[main] INFO hf.depstar.uberjar - Updating pom.xml file to {org.aircraft-noise/util {:mvn/version "0.1.4-SNAPSHOT"}}
[main] INFO hf.depstar.uberjar - Processing pom.xml for {org.aircraft-noise/util {:mvn/version "0.1.4-SNAPSHOT"}}
(! 822)-> cat deps.edn
{:paths ["src" "resources"]
:deps {org.clojure/clojure {:mvn/version "1.10.2"}}
:aliases
{
:artifact-id util
:group-id org.aircraft-noise
:version "0.1.4-SNAPSHOT"
:jar {:replace-deps
{com.github.seancorfield/depstar ; 2.0.next:
{:git/url "<https://github.com/seancorfield/depstar>"
:sha "ee2badaaf4b26754f903ed92e77fd4e82cf2ed70"}}
:exec-fn hf.depstar/jar
:exec-args {:jar "util.jar"
:artifact-id :artifact-id
:group-id :group-id
:version :version
:sync-pom true}}}
}
(! 823)-> more pom.xml
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="<http://maven.apache.org/POM/4.0.0>" xmlns:xsi="<http://www.w3.org/2001/XMLSchema-instance>" xsi:schemaLocation="<http://maven.apache.org/POM/4.0.0> <http://maven.apache.org/xsd/maven-4.0.0.xsd>">
<modelVersion>4.0.0</modelVersion>
<groupId>org.aircraft-noise</groupId>
<artifactId>util</artifactId>
<version>0.1.4-SNAPSHOT</version>
<name>dcj/example</name>
Thanks for trying it out and catching that bug before I released it @dcj !!!
@seancorfield now it works! thank you!!!
@seancorfield What was the reason to delete module-info.class when building uberjar by depstar
? I'm trying to build custom image using jlink, which want the module-info.class inside uberjar.
I don't remember the details on that one. I'd have to hunt through the commits.
So maybe @ghadi has some more insight into why that is an issue?
App vs Lib You don’t want to put a module descriptor in an uberjar, but you do want to put it in a module jar
Ah, interesting. So that exclusion should be dependent on the JAR type then? I had no idea.
@mike1452 Feel free to create a GH issue about it. I'll be cutting a new release probably over the weekend and I can get the fix into that.
Ok, thank you!
But it sounds like an uberjar should not have that file, based on what @ghadi just said.
It is interesting. My case: I made an uberjar and I want to run it in docker image. In order to reduce a size of docker container I want run jlink to reduce size of JDK image. jlink produces custom JDK image based on classes which requires uberjar.
it seems that jar lib should not have that file, but uberjar should.
well I've found workaround so it is not critical for me.
I regularly run jlink without any module info
I use this articel https://www.devdungeon.com/content/how-create-java-runtime-images-jlink I want to create a custom launcher using jlink.
It’s not necessary unless you want autodetection, which won’t help because Clojure libs are ignorant of modules
If y'all figure out depstar
's behavior should be changed, just open a GH issue with deets 🙂 Sounds like "not" at this point?
@seancorfield Yes, "not" at this point. I've found trivial workaround.