Ah, interesting! I see you’re shelling out to Maven for deployment?

Build lacks support for adding project descriptions, URLs and licenses to pom files

No, it specifically supports this now.

That’s good to hear. It looks like that functionality was only added in 2 weeks ago, though.

it expects that you maintain a pom file in source control

Nope. That’s never been true. It’s always been optional.

It’s possible I misinterpreted Alex Miller’s response, but when I asked previously about how to support extra pom data (before :pom-data), that was the answer I was given: “We don’t support lots of elements as we can sync from a source pom[. ]So write the pom template with whatever you need and sync that”

Pretty much everyone has given up on signing at this point, I think? Clojars certainly doesn’t care any more. In other words, this feels like a straw man / moot argument.

I still sign all my packages. I mean, why not? I already have it all set up. It may be that I’m in the minority, but removing signatures would feel like a step backward.

I’m not sure why you consider this a “straw man / moot argument”. Note that I’m not advocating people use Leiningen, I’m just stating the reasons I still use Leiningen.

I know tools.deps and Leiningen/Maven have subtly different dependency resolution logic, but is this a problem in practice? I’ve never run into myself, and surely its trivially fixed by making the dependencies explicit.

tools.build lacks support for adding project descriptions, URLs and licenses to pom files. Or more accurately, it expects that you maintain a pom file in source control, which it then updates and edits for you. By contrast, Leiningen generates one from scratch from the project file.

So in Leiningen you have a user generated project file which you keep in source control, and a machine generated pom file you keep out of source control. In tools.deps, the pom file is intended to be both user and machine edited, an approach I really don’t like.

deps-deploy insists on getting the GPG signing password itself, rather than relying on gpg-agent to manage authentication. This means that if I want to deploy a signed package with deps-deploy, I need to enter my password in every time. Leiningen defers this to gpg-agent, which allows the OS to handle authentication.

I still use Leiningen for libraries, as it currently has better jar generation/deployment functionality than the deps.edn ecosystem.