Clojurians Log v2
clojars
@borkdude See https://github.com/clojars/clojars-web/wiki/Verified-Group-Names 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: https://github.com/clojars/clojars-web/issues/801#issuecomment-841826892
@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”.
well keep in mind relocation won't work for deps/clj yet
That's part of the truth - the other part is folks will push foo/old-lib to com.foo/old-lib, leading to duplication. I'm trying to come up with something that reduces the downstream pains that will cause.
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.
did someone try it? :)
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.
I wouldn't assume that - I think I just get an exception
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)
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)
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?
I'm simplifying a bit, but there are basically two calls made to the primary Maven API (https://maven.apache.org/resolver/apidocs/org/eclipse/aether/RepositorySystem.html) • readArtifactDescriptor is used to get the deps of the artifact (the pom gets downloaded) • resolveArtifact is used to actually download the jar
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)
yeah, the result in the first one has a relocations field with that info
that's certainly somewhat inconvenient in the flow :)
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 com.foo/related-new-lib, and want to have new versions of com.foo/old-lib 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
> so don't want to have `foo/old-lib` and `com.foo/related-new-lib`
^^ but isn't that the truth of it?