This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-07-10
Channels
- # announcements (3)
- # architecture (54)
- # babashka (11)
- # beginners (12)
- # calva (5)
- # clj-on-windows (1)
- # cljdoc (2)
- # cljs-dev (1)
- # cljsrn (6)
- # clojure (130)
- # clojure-europe (8)
- # clojurescript (21)
- # conjure (23)
- # core-async (4)
- # datomic (7)
- # depstar (77)
- # events (1)
- # fulcro (27)
- # lsp (88)
- # malli (5)
- # meander (1)
- # off-topic (4)
- # pathom (43)
- # polylith (39)
- # re-frame (9)
- # shadow-cljs (14)
- # timbre (3)
- # tools-deps (53)
hello, how can I setup SCM
(https://github.com/cljdoc/cljdoc/blob/master/doc/userguide/faq.md#how-do-i-set-scm-info-for-my-project) with depstar?
@wilkerlucio not quite sure what you're asking, or what that has to do with depstar
?
maybe I'm confusing something, but I just started using depstar, coming from Leiningen, there lein used to put the <scm> tag automatically in the pom.xml
. in the case of depstar I'm letting depstar generate the pom.xml, then I though it may have some option on depstar to add the <scm> when generating the pom.xml
so, what I should do is add it to the pom.xml
directly?
If you use clj-new to create a project, it creates a complete pom.xml from a template -- depstar uses the CLI to generate a pom.xml so it is very minimal.
I could replicate clj-new's pom.xml template into depstar I guess, rather than use the CLI/tools.deps.alpha to generate it.
Is there a way to configure depstar to exclude entire deps (and their transitive deps) from an uberjar?
I am trying to get the same functionality of the “provided” maven scope. I have some maven deps that are required at compile-time, but should not be included in the uberjar because they will be provided by the runtime environment that my application is deployed into.
I tried using :exclude
with a regex that matches the name prefix of the direct dependency that I want to exclude but the transitive dependencies of that dep are still included in the uberjar.
I am trying to generate a jar that contains the dependencies of a :local/root sub-project. depstar includes the source code, but does not include the dependencies of the sub-project. What am I doing wrong? Thanks!
@hoertlehner Are you trying to build a (thin) JAR or an uberjar?
clojure -Spom gives me this warning: Skipping coordinate: {:local/root /home/andreas/pinkgorilla/goldly, :deps/manifest :deps, :deps/root /home/andreas/pinkgorilla/goldly, :parents #{[]}, :paths [/home/andreas/pinkgorilla/goldly/src /home/andreas/pinkgorilla/goldly/resources /home/andreas/pinkgorilla/goldly/target/webly]}
Thin JARs never include transitive dependencies.
so then I guess I need to move the extra deps to the main project, and then use alias flag in depstar to include them?
Sorry, I guess it's an assumption that folks know the difference between a (thin) library JAR and an uberjar and so that is out of scope for depstar
's documentation... but I guess adding a section explaining that wouldn't hurt... https://github.com/seancorfield/depstar/issues/93
#!/bin/sh # create pom, including :bundel deps clojure -Spom -A:bundel # add git tag to pom (do not modify git tag) #clojure -M:garamond -t minor #clojure -M:garamond -t clojure -M:garamond:bundel -p # garamond removes deps from :bundel, so we # have to run pom generation again clojure -Spom -A:bundel #create jar clojure -X:jar:bundel :aliases '[:bundel]'
"is there any way to add extra-deps from an alias to the jar with depstar?" -- yes, read the docs for the :aliases
and :compile-aliases
options to depstar
. But, again, thin JARs will never contain transitive dependencies (nor should they).
What you want is those transitive dependencies as actual dependencies in your own project, so they end up in your pom.xml
when sync'd.
so in thin jars ONLY the main dependencies of deps.edn appear as dependencies of te jar?
I need to publish a derivation of my project that contain just a few extra dependencies.
Thin JARs are intended as libraries and should not contain anything but the library. The pom.xml file should declare what dependencies the library needs.
Even bundling those other :local/root
projects could cause problems -- which is why depstar
has a :paths-only
option to make it not do that.
You should not release a JAR containing other libraries.
If you are releasing an application that is intended to be self-contained, that would contain the dependencies. But not a library JAR.
(but an application is expected to be runnable without needing anything but java
)
For a library, any dependencies it needs should simply be declared in its pom.xml
file, not included in the JAR.
I would like to keep the additional deps in a deps.edn file. tis way I can use the clojure tools to check for outdated versions, etc.
but many many thanks @U04V70XH6
Just remember that a library's dependencies are declared in the pom.xml
that is deployed with it (and should match the one inside it). So you can probably use different aliases in your deps.edn
file to represent the different sets of dependencies you want each of your deployed library versions to have, and then you would generate/sync the pom.xml
file from deps.edn
with the appropriate aliases and deploy it with that generated pom.xml
file -- and of course you'll need a unique group/artifact ID pair for each variant. With :target-dir
(new in the most recent depstar
), you could probably arrange to do this, specifying :aliases
, :group-id
, :artifact-id
, :sync-pom true
, and an appropriate :pom-file
option (for the source pom.xml
to use).
But the key point here is that your "variants" should be just about the pom.xml
file you produce -- the JAR won't contain anything from those dependencies.
I do not want to include the jars, but I want to include them as necessary dependencies i the pom.xml
It isn't depstar removing them, it's tools.deps.alpha -- I can see what you mean now (I was focused on the issue of actual dependencies in the JAR before). Let me try something...
Yeah, that shouldn't happen. I'll have to dig into how t.d.a is doing that sync, but I thought it would reflect the :aliases
specified as an option to depstar
😐
Can you just confirm which version of depstar
you are using?
I can get the aliases to be included with just clojure -A:some-alias -Spom
but it doesn't seem to work programmatically -- so I'll have to dig into that difference over the next few days.
#!/bin/sh # create pom, including :bundel deps clojure -Spom -A:bundel # add git tag to pom (do not modify git tag) #clojure -M:garamond -t minor #clojure -M:garamond -t clojure -M:garamond:bundel -p # garamond removes deps from :bundel, so we # have to run pom generation again clojure -Spom -A:bundel #create jar clojure -X:jar:bundel :aliases '[:bundel]'
so I tried first generating pom file , then using garamond to add git tag version to pom, then running clojure pom generatuin AGAIN so the deps would be in te pom
Unfortunately I cannot do the same trick with depstar because ten I would have to manually edit the jar file.
If you do not sync the pom, depstar
will take it as-is -- try :sync-pom false
(or just remove that option, it should default to false).
@hoertlehner This is fixed in depstar
2.1.253 -- but I need to discuss my workaround with Alex re: tools.deps.alpha
behavior as this may be a bug in t.d.a
Yup, it does, based on my tests. And the t.d.a issue does seem to be a bug.
@hoertlehner This is fixed in depstar
2.1.253 -- but I need to discuss my workaround with Alex re: tools.deps.alpha
behavior as this may be a bug in t.d.a