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.


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)


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.


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


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


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


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


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


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


I never saw that before


seems like there are a lot of those out there


seems good to me :)