Clojurians Log v2

https://repo.clojars.org/com/janetacarr/quadtree-cljc/0.1.3/ -- looks like you uploaded the -standalone JAR which would be the application, rather than the library JAR?

There's no application, but does the name of the jar itself matter?

Apparently, yes. I would sort of expected deps-deploy to handle that renaming for you...

oh so the jar should be named quadtree-cljc-0.1.3.jar then ?

That should work, yes. You'll have to deploy 0.1.4 now, but...

No wait, let me check one of my projects...

https://github.com/seancorfield/next-jdbc/blob/develop/build.clj#L55 -- yeah, lib-version.jar

(although in my case that path ends up being target/com.github.seancorfield/next.jdbc-1.3.909.jar -- but the trailing part is artifactID-version.jar)

the maven deploy plugin renames the jar to this format

But deps-deploy does not, it seems.

or maybe it's nexus that renames it, I guess I'm not sure where that happens exactly, but when it ends up in the repo it has to follow the repo naming conventions to be found

This is for Clojars -- so maybe that's why there's no renaming?

This does work by the way:

clojure -Sdeps '{:deps {com.janetacarr/quadtree-cljc$standalone {:mvn/version "0.1.3"}}}'

ah so it is the jar name then

(this is orthogonal, but I notice there is an older 0.1.14 version - maybe a typo when deployed, and by Maven version comparison rules that will look newer than 0.1.3 or 0.1.4)

(so I guess that's why there is no renaming here -- because <artifact>-<classifier>-<version>.jar is perfectly reasonalbe)

@alexmiller yes, a mistake. 😅

https://repo.clojars.org/com/janetacarr/quadtree-cljc/0.1.0/ has the only version that would work directly -- without -standalone

when you do a maven deploy you either tell it coords or give it a pom that has them - it will write the jar to the place according to those coords. I guess maybe the clojars upload doesn't do the same when publishing

seems like that would be a good thing for clojars to at least validate (coords match the artifact name)

@seancorfield that's funny because 0.1.0 is the only version built with your build-clj lib haha

Sane defaults 🙂

This is why https://clojure-doc.org/articles/cookbooks/cli_build_projects/ exists now instead 🙂

@alexmiller that'd be nice.

I have half reading the cookbook haha

I wonder how clojars / deps-deploy should handle multiple artifacts with classifiers...? Although that's a question for a different thread I guess 🙂

@alexmiller @seancorfield that was the problem. 0.1.4 works 🙂

I think I have a blog post to update somewheres.... Anyways thanks to the both of you!

I'll add a note to http://clojure-doc.org and also chat to Erik about deps-deploy helping prevent this. https://github.com/clojure-doc/clojure-doc.github.io/issues/68

multiple artifacts with different classifiers all share the same pom and usually they are uploaded as part of the same deployment (with normal maven deploy plugin)

> when you do a maven deploy you either tell it coords or give it a pom that has them - it will write the jar to the place according to those coords. I guess maybe the clojars upload doesn't do the same when publishing > seems like that would be a good thing for clojars to at least validate (coords match the artifact name) Clojars does verify that the version, group, and artifact name you are trying to deploy (via the path) matches what is in the pom. It doesn't parse the version from the jar file name to confirm that though. Did you see an example where there was a mismatch? I didn't see a mismatch in any version of this project. And I think Clojars did the right thing here otherwise unless it should be invalid to deploy a classified jar without a non-classified one.

@tcrawley The issue was that Janet uploaded <artifact>-standalone-<version>.jar via deps-deploy and that is a perfectly valid pattern -- it just treats standalone as a classifier -- so it can be depended on if you add $standalone to the group/artifact libname. So the libname and version part matched, and Clojars allows for classifiers -- and Clojars accepted it (correctly, IMO).

Thanks @seancorfield! I got that part, I was just curious if @alexmiller spotted a version inconsistency while looking at this, given the above statements. I agree that I think Clojars is doing the correct thing otherwise.

wasn't the intent to NOT use a classifier though?

maybe I misunderstood

With maven deployment, that's how a classifier is specified to the server (in the jar name). So Clojars has no way to know that wasn't the intent.

in fact, maven repos have no knowledge of classifiers. It's only the clients that have the convention to append the classifier to the name when deploying or retrieving.

Since a maven repo is really just a remote filesystem.

@alexmiller The core issue is that deps-deploy uploads the JAR file with the name as-is, and <artifact>-standalone-<version>.jar is a perfectly valid filename for Maven/Clojars and matches the artifact and version just fine. So Janet had no idea there was a problem. And since standalone was acting as a classifier -- per @tcrawley’s comment -- you could depend on com.janetacarr/quadtree-cljc$standalone and everything "worked as expected". I created an issue for deps-deploy since that's where this could have been caught, in theory.

(and, yes, Janet's intent would have been to "NOT use a classifier" but that's on deps-deploy to prevent)

when you deploy should be specifying a classifier if you expect to use one. and whether you do or not should be in sync with the file name. the maven deploy plugin rewrites the jar file name to ensure these match.

Right and deps-deploy does not which is the issue here.

I got that and agree, was repsonding to Toby

I think we're all in agreement at this point 🙂 The maven deploy plugin prevents this footgun.