You would need to extend Gradle and Maven as a starter so they can understand Clojure's git coordinates and Clojure deps.edn files and be able to run prep tasks. And then you'd need to build a git proxy layer that can proxy lazily so that somehow if you ask for a repo from it, it knows to check GitHub and GitLab and BitBucket for the same and if it finds it automatically clone it inside the repo. Then you'd need to convince your leadership to have people maintain and operate that git proxy as well as the existing proxy for Maven repos. And then you'd need to convince other teams who use Java or Scala that they should configure their Gradle or Maven build tooling to use the plugin that enables them to also pull Clojure deps from that git proxy.

Git proxies like this exist now

What's their name?

I guess, I'm not saying that you cannot work around these problems with additional effort and setup, just that it makes the barrier to adoption even higher in an existing Java shop.

It would also be especially weird in transitive contexts. Someone could pull a Java lib that depends on a Clojure lib, and now they too somehow are faced with this not just working as-is, but need to setup some plugin in their own build tooling as well, and so on.

It might be weird, it might have problems, it might incur extra costs. Which doesn't mean that it automatically creates an island or makes something impossible. My whole argument is with the specific words that you used - "becoming an island" and "no other JVM language can use Clojure libs". Which is simply not the case with Git coordinates.

Building a bridge doesn't mean it isn't an island. The fact is, today Clojure used the same mechanisms for releasing and pulling in dependencies as the rest of the JVM ecosystem, which is it did so through jars in Maven repositories and Pom xml files. With git deps, it no longer does so, it uses its own thing. Thus if Maven is the mainland, Clojure git deps are an island next to it. And a bridge would need to be built and maintained for them to interoperate.

You're correct about my choice of words for "No other JVM language can use Clojure libs". I added the word "transparently" afterwards (just edited it), to reflect the correct meaning. Thanks for that.

I am in the camp of "you need both" consuming libs with git coords is fine, services no. In general you wouldn't want your services to do deps resolution at startup (they'd require credentials etc), so you build them as (uber)jars

git deps can cut dramatically the CI/CD workflow, no need to wait to build/deploy the chain of deps, as soon as you commit in one of your deps it's available everywhere

another pro of (uber)jars is that you can avoid the extra cost of some of the compilation at startup, sometimes it matters (like in kubernetes & co)

typical "it depends" answer 🙂

Ya, to be clear, I'm specifically talking about releasing open source libraries and consuming open source libraries, assuming you are the author of such a library. If you only publish your OSS library as a git deps, then you cannot transparently consume it using Gradle, Maven, Lein, Boot, etc. And any library that consume it through a git deps, themselves can no longer be consumed from those build tools either. Similarly, since you're no longer in Maven, anyone that used tooling build around Maven, such as a mirroring repository and others, will not be able to do what they were achieving with those tools anymore with regards to your library.

That's why I hope, in the spirit of reach, that as a community we continue to advocate for releasing your OSS libraries to Maven Central or Clojars additionally to having them available as git deps, with a preference for Maven Central since it has even more reach.

Also, I just realized, and I don't think it was mentioned - if you have an OSS library that you don't want to publish anywhere yourself as a JAR, it doesn't prevent anyone else from doing that. So the situation is even better. Exactly like it happens in the world of software packages on Linux - usually it's not the developers of the software that create packages for all the OSes.

Both Clojar or Maven will prevent you from publishing unless you are the owner of the git repository or group-id. You can publish it under a different group-id though, but it creates an issue of trust. I think it will also not work in the transitive dependency case. Like if I depend on a library that depends on a git deps, even if I publish the library to Maven, I cannot update the pom.xml of the library to depend on the Maven location. I guess you'd need to make the transitive dependency one of your own, and now you have to carefully make sure you update the library and it's dependencies manually with the correct versions and all that. I also am not sure about Maven Central, I think for Java they even assert the group-id matches the package name of the classes. Anyways, I can't force someone to go the extra mile and have them release their OSS lib to Maven, but I can guarantee you there are some people that might need to avoid your library due to the extra leg work required on them if they are using Lein, Gradle, Boot, Maven, etc. Even more so if they are using Java, Scala or Kotlin. So I'm just inviting people to consider that and decide what level of reach they want for their OSS lib.

and btw, why does installing via mvn work? Shouldn't I hit the same problem?

I'm pretty sure in order to use :local/root, the referenced project itself has to use deps.edn as well.

If I were in your case, I would probably do that with a Git submodule and a changed :paths entry in deps.edn. Alternatively, you can still use your own fork, but you need to create deps.edn there as well.

thanks @U2FRKM4TW, googling around earlier I found https://ask.clojure.org/index.php/8507/failure-on-github-import-via-deps which suggest to create a deps.edn which only contains dependencies. This works, but I fear losing other functionality (I mean, the other parts of the project.cli file do something, right?

interesting, let me read about :paths

They surely do something, but it's up to you whether you need that something or not.

And you won't really lose it - as long as you don't delete project.clj. But then, if you don't use lein - what's the point on having that file around?

Hmm, I don't really know what I would be losing; I'm mainly concerned that I'll miss some configurations in a cljs build. But I guess I'll wait and see 😄

I did put:

cljfmt/cljfmt {:mvn/version "0.8.0"}

Put it into a separate alias and use it as needed.

here's the thing, emacs should use it automatically on save (it's configured to do that, but probably it's not finding the program)

There's no program - it's the same clj, just with specific arguments: https://github.com/weavejester/cljfmt#toolsdeps

I'm quite confused by this; for this feature to work, I don't even need a repl: it's all part of the lsp-server

so I'm not even sure that I should be starting something manually

said differently: does clojure-lsp have its own cljfmt (cc @UKFSJSM38)?

I think there's also a program though, they ship a binary I think?

or should you compile it yourself?

by my googling right now I don't think there's a program, and what @U2FRKM4TW pointed to is the correct invocation for the cli, but in my case I think I just need to configure the options for the lsp-server, so my idea of installing cljfmt was misguided in the first place

yep, problem solved for me by creating a configuration file in ~/.lsp/config.edn and restarting emacs

clojure-lsp already ships with cljfmt :)

Check cljfmt setting: https://clojure-lsp.io/settings/#all-settings

I don't think there's a command to run cljfmt against a whole project/dir tho

@UKFSJSM38

it's either buffer or region (lsp-format-buffer or lsp-format-region)

There is via clojure-lsp API: clojure-lsp format

ahh

https://clojure-lsp.io/api/#usage

You could use from an shell command or via your repl, but I suggest adding to your CI or something

https://github.com/clojure/tools.build/blob/master/deps.edn#L24-L31

with the caveat that it seems to fail on newer jvms so I use Java 8

I've also been using codox for some projects. I haven't noticed it didn't work on 11 for me

don't remember why

maybe i'm even wrong ;)

fwiw this is how I apply codox to gh-pages: https://github.com/babashka/fs#codox

to not "pollute" the main branch, but I do have projects where I do that as well

Hmm. Well thanks for the snippet, maybe I can try codox again.

Although we'll see if it works, because this is for java 17

Codox is not working on 16+ https://github.com/weavejester/codox/issues/197

That explains why I wasn't able to get codox working on the last project I was testing with. I have been using java 16 for a while now.