Repository navigation
Moving clojars artifact to com.lambdaisland groupId #2
Description
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.
- Support Maven groupId relocation 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/projof 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.
Activity
alysbrooks commentedon May 7, 2021
I can look into Leiningen's support for this feature.
alysbrooks commentedon May 7, 2021
What do you think of Tobias' solution?
This seems like something we could build into
bin/proj, but I'm not sure if it solves the problem of the old and new artifacts being treated as separate libraries. I'm guessing not, except for Maven and (probably) Leiningen?plexus commentedon May 12, 2021
I've commented on the Clojars issue. I think this solution has the risk of causing weird and hard to track down bugs, so it's not my preferred solution.
plexus commentedon May 12, 2021
Leiningen supports seems to be fine, but it does cause incorrect results in
lein deps :tree.vemv commentedon Apr 21, 2022
In case it helps - I heard that
antqdetects renamed artifacts?(Don't know how that works)
It doesn't solve the problem directly, but it gives some peace of mind i.e. "users who really care about this sort of problem have some means of detecting it"
plexus commentedon Apr 22, 2022
We'll look into that because right now I'm not aware of a way for us to signal that that's compatible with Clojars.
plexus commentedon May 18, 2022
Tried it out, antq does not pick up relocated artifacts (it does not rename the group)
plexus commentedon May 31, 2022
After discussion on Clojars and some more research we have decided to not go ahead with this, we'll basically live with the split world forever.
The reason is that to do Maven relocation properly, you need to change the poms of all previously releases too, to point at the new location, and that's not something that Clojars is willing or able to do. So we will stick to
lambdaislandfor older libraries, and usecom.lambdaislandfor anything where we're not allowed to uselambdaisland.Unfortunately the damage has been done, we have four artifacts that exist under both names:
For these going forward we will deploy two poms/jars with every release, with the
lambdaislandversion being an empty artifact that has thecom.lambdaislandversion as its only dependency. So thecom.lambdaislandone becomes the canonical one, but tools will be able to upgrade thelambdaislandversion too, and dependency resolution should in most cases work correctly.