Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2020-10-11

Channels

#cljdoc
<
2020-10-11
>
miikka03:10:31

Heh, now that I have figured tihs out, maybe I'll go to fix Malli...

miikka03:10:28

Or maybe not. Ah well. Maybe I'll document it on the issue tracker of Malli.

dominicm12:10:09

I have some time this afternoon to have a stab at fixing that a little bit so pom.xml is less required.

💪 3
lread14:10:06

So if I understand correctly, the .pom file in the maven repo is a copy of pom.xml. But cljdoc is relying on the pom.xml in the jar, which some jars don’t include?

martinklepsch15:10:54

the POM is accessible via the repo url and most packaging tools include it inside the jars „META-INF“ directory. In some places we rely on the file being included inside the jar but I’m not 100% sure if that’s a cljdoc thing or a tools.deps thing

dominicm15:10:23

tools.deps can fetch deps without it being in the META-INF dir

martinklepsch15:10:44

Tools deps supports adding a jar as a dependency in which case it has(?) to rely on the pom being inside the jar

dominicm15:10:14

I think analysis doesn't need to use that jar though

dominicm15:10:33

It would be duplicate work, but it could just use the project instead of the jarpath/pompath.

dominicm15:10:13

The other option is to download it and then just assume the location in $M2, checking that out now too.

dominicm15:10:23

Maven always downloads the pom, so we wouldn't need to know urls

dominicm15:10:23

Oh I see, we also always download the pom. Even less of a problem then :)

dominicm15:10:29

In fact, we're already parsing the pom...

dominicm15:10:18

For example, this (contains? #{"provided" "system" "test" "compile" "runtime" nil} (:scope %)) will solve the problem where the pom is already used.

dominicm15:10:24

But I have a slightly better way too :)