Fork me on GitHub
#tools-deps
<
2020-07-16
>
markbastian19:07:43

If I want to publish a tools deps project as a jar to a repo (e.g. clojars) and I have an up-to-date pom.xml, what is the "right" artifact to publish if you are using git coordinates for your dependencies? Do I need to create an uberjar and publish that? Is there a way to package the git deps src in a regular jar target? This is assuming a library project with git dependencies.

Alex Miller (Clojure team)20:07:13

there is no way to do that

Alex Miller (Clojure team)20:07:26

git deps are only usable from source deps

Alex Miller (Clojure team)20:07:21

as soon as you say "artifact", you're talking about maven and you need to depend only on other artifacts

markbastian20:07:05

Makes sense. Seems like an uberjar as lib or jar + git deps as lib would be a mess.

kenny20:07:51

Is there a Maven command or Clojure lib someone made that uploads a jar file to a S3 bucket? All the tools I've found seem like they expect to build the jar for you.

Alex Miller (Clojure team)20:07:52

well you can just do an aws s3 cp if that's sufficient

kenny20:07:06

I tried that and receive this message from tools-deps "Download corrupted: Checksum validation failed, no checksums available." It actually all works (i.e., jvm starts up with the jar on the cp) but it'd be nice to do it the correct way.

kenny20:07:33

Or maybe that's a bug in tools-deps?

Alex Miller (Clojure team)20:07:53

well if you just upload the jar without the checksum files, you will see this message

kenny20:07:43

I figured. Is there something out there that can do this the correct way to avoid this warning?

Alex Miller (Clojure team)20:07:13

the correct way is to compute an md5 or sha1 checksum for the jar and upload those (and ideally to gpg sign all of those files as well). I do not know of a tool that does that (although I have started working on one)

Alex Miller (Clojure team)20:07:50

how that all gets created and uploaded is quite complicated, and clojars does much less (and even less is really required)

Alex Miller (Clojure team)20:07:20

really, just the jar and the md5 or sha1 file (and ideally the pom) are probably sufficient

Alex Miller (Clojure team)20:07:04

you can use a tool like sha1sum or md5sum to make that

Alex Miller (Clojure team)20:07:29

there is also a version metadata file that should be updated too (like https://repo1.maven.org/maven2/org/clojure/tools.deps.alpha/maven-metadata.xml) if you want something like RELEASE version to work.

kenny20:07:16

Wowza. Did not realize what I was getting myself in to. Thank you for all this info. I assume the work you started on is not public yet?

Alex Miller (Clojure team)20:07:12

I would like to handle a) clojars b) s3 and c) maven central in that order which I think handles both the most common and easiest items first

3
Alex Miller (Clojure team)20:07:46

there are multiple options on each and it is way harder than it should be for sure

kenny20:07:31

Will try the jar + hash suggestion. And try to restrain myself from building something complete. Thanks again 🙂

dominicm21:07:25

Maybe I should build a tool on top of pack. It would force me to finish the api.

Drew Verlee22:07:38

For deps that need to be kept in sync, or even in times where its likely two things should udpate together, what strategy have people used? My first thought would be that deps wouldn't be responsible for this and this more when you need a tool like lein. But if i only have this issue maybe soemthing a tad more lightweight.

seancorfield22:07:26

@drewverlee I put them next to each other in deps.edn with a comment explaining the relationship.

seancorfield22:07:58

(it's a project/application concern, not a tooling concern really -- so it's more about making sure people know how/when to change stuff)

seancorfield22:07:16

BTW, that's also why I'm generally against tools that update my configuration files automatically -- those tools cannot know about such constraints, e.g., I may have very valid reasons for keeping two particular dependencies on older versions together, even if newer versions of one or both exist.

Drew Verlee23:07:09

Seems reasonable, I guess I should start with the comment and add more as needed. Thanks @seancorfield