Fork me on GitHub

@borkdude See for the full details on the new process, and I'm happy to answer any questions


@seancorfield we may discourage double pushing, since it can lead to issues with having two versions of a jar on the classpath when brought in transitively, where lib A depends on the old name and lib B depends on the new. But we may have a solution to that using Maven's relocation mechanism. I'd love your feedback on that if you have time:


@tcrawley I’d be happy to switch to relocation for any libs that I’m currently double-publishing. I wasn’t planning to double-publish for much longer anyway, given antq is doing a good job spotting the group name “changes”.

Alex Miller (Clojure team)16:05:01

well keep in mind relocation won't work for deps/clj yet


Right - the "relocation" plan is a pom with a relocation stanza and a dependency on the new name, so tooling that doesn't support relocation will still have the new name in the dependency tree. Let me know on that issue if you have concerns with how that will work with deps.

Alex Miller (Clojure team)16:05:48

it kind of depends on what happens through the maven api in that case - I don't know off the top of my head


Not yet! I haven't looked at the API at all to see how relocation is handled, but assumed if relocation didn't work for tools.deps, the stanza was just being ignored and the pom was being treated as a regular pom. But, well, assumptions.

Alex Miller (Clojure team)16:05:26

I wouldn't assume that - I think I just get an exception

Alex Miller (Clojure team)16:05:25

from doing a few quick tests, I think the expansion works (finding deps of the relocated artifact), but then it will ask for the jar of the relocated artifact and that just fails with an ArtifactResolutionException (as if the artifact didn't exist, which I guess it doesn't)

Alex Miller (Clojure team)16:05:23

without doing some more digging, not sure if I can tell the relocation is why it fails or how to resolve this earlier (I assume there is a way)

Alex Miller (Clojure team)16:05:31

but I would not assume this will work with deps/clj now


Hmm, if we do this correctly, the jar should exist. Are you saying with a pom that has a dependency on the relocation, it finds that dep, but it is too late in the resolution process to resolve that dep?

Alex Miller (Clojure team)17:05:39

I'm simplifying a bit, but there are basically two calls made to the primary Maven API ( • readArtifactDescriptor is used to get the deps of the artifact (the pom gets downloaded) • resolveArtifact is used to actually download the jar

Alex Miller (Clojure team)17:05:11

I think the first one works but the second one fails (perhaps there is sufficient info in the first result to avoid the failure in the second)

Alex Miller (Clojure team)17:05:25

yeah, the result in the first one has a relocations field with that info

Alex Miller (Clojure team)17:05:22

that's certainly somewhat inconvenient in the flow :)

Alex Miller (Clojure team)17:05:18

Why don’t you just put new things in the new place?


Does the result of the first call not include any dependencies from the pom? > Why don’t you just put new things in the new place? New things are in new places. Folks want consistency in group names, so don't want to have foo/old-lib and, and want to have new versions of that is a continuation of foo/old-lib. This may be partially driven by a false stigma that I've introduced with verified groups. The old group will never be verified, so will lack a badge in the UI.


We won't allow relocation of any existing versions

Alex Miller (Clojure team)18:05:48

> so don't want to have `foo/old-lib` and ``

Alex Miller (Clojure team)18:05:56

^^ but isn't that the truth of it?


That's part of the truth - the other part is folks will push foo/old-lib to, leading to duplication. I'm trying to come up with something that reduces the downstream pains that will cause.