Fork me on GitHub

Realized after the fact there is a Clojars channel


Okay, my best idea to move forward with something of that sort would be that when someone pushes to Clojars and the groupId doesn't already exists, Clojars would: If groupId is a reverse domain like Check that the domain has TXT DNS header for with value equal to If check fails, refuse to create the group. Else if it has a groupId like github-foo Check that the github user foo has a public repo called _clojars with a readme file that contains the value github-foo. If check fails, refuse to create the group. Else proceed to create the group as current assuming other validation pass.


Similar things could be added for gitlab-foo and bitbucket-foo etc.


Now that way, going forward, I know that if I depend on a lib with a groupId that is a reverse domain or a github-foo like format, that the origin was verified and I can trust it comes from the real domain owner or the real repo owner on GitHub.

Alex Miller (Clojure team)12:10:34

Just as a point of comparison, with maven central a human is involved in granting access to new groupids (but I have no idea what level of rigor is involved)


You can see an example of the maven central verification process here:


It is similar to what is proposed above, but with human verification


Clojars came about in part as push back to the maven central verification requirements (though, at the time, I think central didn't support com.github.username groups). If we want to move towards verified groups, I think we should push folks to deploy to maven central instead of modifying Clojars to do the same thing


Releasing to central is a bit more painful, given that deploys go to a staging repo then have to be released manually. But there is mvn tooling to to that automatically, and it wouldn't be difficult to build a lein/`boot` /whatever plugin to do that (if they don't already exist)

Alex Miller (Clojure team)12:10:04

Actually, it is fairly difficult due to gpg signing


Ah, good point


Since gpg signing isn't that useful, let's just generate a new gpg key automatically for every deploy :)


Hum, the manual process is also painful. If the above is automated, I can in 5min have a new groupId for my open source project pushed to Clojars. But with Maven Central it takes a few days of turnaround


That's definitely true.


I'm also considering the effort to build & maintain that system in Clojars


Ya that's a very fair consideration.

Alex Miller (Clojure team)17:10:24

a) you should ideally only have 1 (or small number of) groupIDs

Alex Miller (Clojure team)17:10:52

b) and if a, ~day turnaround is no big deal

Alex Miller (Clojure team)17:10:52

but I do think the automated path via dns is a reasonable automated check and certainly in line with what others things do


It seems Maven established a different convention for github? And they do com.github.user where as right now in the Clojure community I think I saw recommendation for github-user. I think I like the latter better because of the possibility for github to want to own the com.github groupId for their own projects. But I can see an argument for both

Alex Miller (Clojure team)17:10:00

I'm not familiar with the Maven convention if there is one

Alex Miller (Clojure team)17:10:25

the latter recommendation was due to not wanting to stomp on github's own "space"

Alex Miller (Clojure team)17:10:19

and to suggest ways to use other identities as a means of borrowing ownership: twitter-puredanger, gitlab-foo, etc


I'm just going off from that link, seems they approved the creation of groupId com.github.user once the person proved they owned the repo under that user in GitHub. But I like the identityprovider-user approach personally for the same reason that you can't think that's a github published repo

Alex Miller (Clojure team)20:10:32

I never saw that before