This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-08-22
Channels
- # announcements (13)
- # babashka (22)
- # beginners (22)
- # biff (17)
- # calva (6)
- # clerk (20)
- # clj-kondo (25)
- # clj-together (5)
- # clj-yaml (20)
- # cljdoc (16)
- # cljs-dev (1)
- # clojure (42)
- # clojure-brasil (1)
- # clojure-europe (26)
- # clojure-nl (6)
- # clojure-norway (24)
- # clojure-turkiye (3)
- # clojure-uk (5)
- # clojurescript (37)
- # core-async (7)
- # core-logic (2)
- # datalevin (7)
- # datomic (43)
- # events (2)
- # fulcro (7)
- # gratitude (1)
- # hyperfiddle (7)
- # java (7)
- # jobs (3)
- # lsp (4)
- # off-topic (16)
- # pathom (18)
- # polylith (1)
- # portal (27)
- # reitit (4)
- # releases (3)
- # shadow-cljs (47)
- # tools-build (14)
- # tools-deps (16)
- # yamlscript (11)
hi, first time deploying a library and I'm having some trouble getting cljdoc to discover my sources. The build is throwing a FileNotFoundException
when loading the public API namespace for my lib. If I load the JAR locally though, I can access this ns without any issues.
It's probably going to be down to the contents of the pom.xml
file in the JAR.
Which lib/version are you talking about?
I suspect this is your culprit: <sourceDirectory>src/com/slothrop/clj_baseball</sourceDirectory>
-- should just be <sourceDirectory>src</sourceDirectory>
(in your pom.xml
)
Thanks! I was confused about that, I thought it had to match the directory I copied in my build.clj
.
Hey @U03QBKTVA0N I don't know if you sorted this one out. But if I look at the failing cljdoc build, I see:
Could not locate com/slothrop/clj_baseball/api__init.class, com/slothrop/clj_baseball/api.clj or com/slothrop/clj_baseball/api.cljc on classpath
But if I download the library jar from clojars: https://repo.clojars.org/org/clojars/slothrop/clj-baseball/0.3.2/clj-baseball-0.3.2.jar
And then take a look at the contents:
$ unzip -l ~/Downloads/clj-baseball-0.3.2.jar ✔ 04:10:30 PM
Archive: /home/lee/Downloads/clj-baseball-0.3.2.jar
Length Date Time Name
--------- ---------- ----- ----
82 2023-08-22 10:01 META-INF/MANIFEST.MF
316 2023-08-22 10:14 api.clj
0 2023-08-22 12:01 statcast/
0 2023-08-22 12:01 player/
0 2023-08-22 12:01 META-INF/
4523 2023-08-22 10:15 statcast/results_spec.clj
3740 2023-08-22 10:14 statcast/batter.clj
787 2023-08-22 10:15 statcast/utils.clj
12236 2023-08-22 10:15 statcast/specs.clj
3658 2023-08-22 11:33 player/lookup.clj
904 2023-08-22 10:14 player/profile_spec.clj
0 2023-08-22 12:01 META-INF/maven/
0 2023-08-22 12:01 META-INF/maven/slothrop/
0 2023-08-22 12:01 META-INF/maven/slothrop/clj-baseball/
124 2023-08-22 12:01 META-INF/maven/slothrop/clj-baseball/pom.properties
2145 2023-08-22 12:01 META-INF/maven/slothrop/clj-baseball/pom.xml
--------- -------
28515 16 files
That api.clj
in the root of the jar seems suspicious... it should probably be under com/slothrop/clj_baseball/api.clj
, no?
The other sources seem suspicious too. Dir structure in your jar should match your https://github.com/bhlieberman/clj-baseball/tree/master/src dir (minus the src
dir). I think something is off with your jar building.hey, yeah, I think it is. I'm gonna reorg the whole src directory again bc I've definitely messed something up.
Oh yeah, https://github.com/bhlieberman/clj-baseball/blob/d7b75d126ab7394a0754bacb8d0ff46899d9be5b/build.clj#L18-L19. These would typically simply be :src-dirs ["src"]
The reason I did it this way was some of those subdirs are still in the works and I didn't want to include them in the jar
In an ideal world you'd want your jar sources to match your git sources at time of release. My take: it is easier to stay sane this way.
You could move wip to a branch... and keep your build simple.
Or if you prefer to work this way (no judgement here), you'll need to modify what goes into your jar. Perhaps the :include
option on https://clojure.github.io/tools.build/clojure.tools.build.api.html#var-copy-dir would help you. Or do your own custom copy or fixup with deletes afterwards.
the branch is a good idea, I think. I'm fine with that. I'm a bit clueless when it comes to Java packaging and all its details so the less knobs I have to turn the better (for the time being at least)
Yeah, that would be what I'd do too. Make your git repo main branch represent what you want to actually release, then release, then merge your wip branch into your main branch.
Will do! Thanks @UE21H2HHD