lambdaisland/open-source

A collection of Clojure/ClojureScript tools and libraries

open-source's Issues

Moving clojars artifact to com.lambdaisland groupId

With the new Clojars policies we can no longer release new libraries as lambdaisland/..., we have to release them as com.lambdaisland/.... For existing libraries we could keep using lambdaisland/..., but that would mean keeping track of which ones are "new world" vs "old world" across over a dozen libraries, so we would rather move forward and re-release everything as com.lambdaisland/....

I started doing this to some of them, so far we have

com.lambdaisland/glogi
com.lambdaisland/kaocha-cljs

And one library which had to be released to com.lambdaisland, because it saw its first release after the policy change:

com.lambdaisland/daedalus

However this puts a burden of churn onto our users, which is something we generally really like to avoid. It also causes potential issues, since now Maven et al see these as two separate libraries, even though it's really one and the same, and so you may end up with two versions of the same library on the classpath. Not a recipe for success.

The clean solution would be Maven's "relocation" feature, which solves exactly this. It allows pushing a pom without a jar to the old artifact id, containing a relocation stanza pointing to the new group id.

However Clojars does not currently allow deploying a pom without a jar, and Clojure CLI/tools.deps don't yet understand Maven relocation. The issue stems from 2017 with little to no activity since, and my sense is we might have to contribute these features ourselves if we want to see them happen. Ideally Clojars would have first class support for relocation, so one can indicate moving to a new group without having to deal with poms.

• clojars/clojars-web#801
• https://clojure.atlassian.net/browse/TDEPS-8

We'll also have to check what Leiningen does. My guess is it will support relocation since it uses established tooling under the hood, but it should be checked.

Until these things are cleared out we'll continue to release old libs under lambdaisland, with the exception of the three above that have already moved.

Next steps:

• adapt LIOSS build tooling so we can specifiy the groupId in bin/proj of each project
• verify that Leiningen can handle relocation
• follow up on TDEPS-8, possibly submit patch
• follow up on clojars-web#801

FAQ

• Why don't you keep using lambdaisland, doesn't Clojars grandfather existing groups?

Only existing libraries are grandfathered, we are not allowed to release new libraries under lambdaisland.

• Will you also be prefixing namespaces with com.lambdaisland?

No, there is no plan for that at this time. Clojure also provides clojure.core and not org.clojure.core. It would be sensible to use full reversed domains there too, but that would be a lot of extra churn, which we really like to prevent.

Add `:old-group-id` support

Currently in bin/proj we set the Maven group-id, e.g. here is the bin/proj for Facai

#!/usr/bin/env bb
(ns proj
  (:require [lioss.main :as lioss]))

(lioss/main
 {:license                  :mpl
  :inception-year           2022
  :description              "The ultimate factory library"
  :group-id                 "com.lambdaisland"
  :version-qualifier        "alpha"
  :aliases-as-optional-deps [:jdbc]})

As explained in #2 , we have a few projects that have previously been released under lambdaisland, where at some point we switched to com.lambdaisland. For these we want to still release a version under lambdaisland, but one that is nothing but an empty jar (only containing the pom), with a single dependency on the com.lambdaisland version. We'll specify this through a new option in bin/proj: :old-group-id.

:group-id "com.lambdaisland"
:old-group-id "lambdaisland"

If this key is present the release process (see lioss.release/do-release), after deploying the main artifact, will create a pom.xml in a temp directory, and then mvn deploy it from there.

We'll need to implement the single-dependency-pom, see lioss.pom/regular-pom and lioss.pom/relocation-pom. This new pom will not have a relocation stanza (we're not actually using Maven relocation support), it will have a <dependencies> section pointing at the previously released artifact.