Moving clojars artifact to com.lambdaisland groupId
plexus opened this issue · 8 comments
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.
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.
I can look into Leiningen's support for this feature.
What do you think of Tobias' solution?
Given a project foo/bar that has versions 1.0.0 and 2.0.0, and there is a desire to move to com.foo/bar, the project owner could:
push com.foo/bar 2.0.1 that has the same functionality as foo/bar 2.0.0 push foo/bar 2.0.1 that has that same functionality again, but with relocation in the pom that points to com.foo/bar 2.0.1
Then any tooling that doesn't support relocation can still use foo/bar 2.0.1, since it is a real release, and anything that depends on foo/bar 1.0.0 will continue to work. But tooling that does support relocation can find com.foo/bar when depending on foo/bar 2.0.1.
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?
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.
Leiningen supports seems to be fine, but it does cause incorrect results in lein deps :tree.
In case it helps - I heard that antq detects 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"
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.
Tried it out, antq does not pick up relocated artifacts (it does not rename the group)
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 lambdaisland for older libraries, and use com.lambdaisland for anything where we're not allowed to use lambdaisland.
Unfortunately the damage has been done, we have four artifacts that exist under both names:
- daedalus
- funnel-client
- glogi
- kaocha-cljs
For these going forward we will deploy two poms/jars with every release, with the lambdaisland version being an empty artifact that has the com.lambdaisland version as its only dependency. So the com.lambdaisland one becomes the canonical one, but tools will be able to upgrade the lambdaisland version too, and dependency resolution should in most cases work correctly.