Clojurians Log v2

one can use xmllint as well for getting the version out like here: https://github.com/replikativ/hasch/blob/87410246864f2e160cccac3a51f7a7e3139c3c45/.circleci/config.yml#L123 but setting it probably mvn plugin like @alexmiller does in the release script.

https://github.com/workframers/garamond offers a way to set the version in pom.xml. If you are using your own versioning scheme you can use its --force-version option.

In the past I have also used maven to do this type of work, for example to update the tag and version:

mvn versions:set-scm-tag -DnewTag=$(git rev-parse HEAD) -DgenerateBackupPoms=false
mvn versions:set -DnewVersion=$(bin/generate_version) -DgenerateBackupPoms=false

anyone tried the clj prerelease yet?

https://github.com/DeLaGuardo/setup-clojure btw, github action support prerelease as well. Might make the way to try it a little bit easier 😄

I haven’t, but I’d like to do it today

:thumbsup:

Installed it Monday night and integrated it into our dev/test/build pipeline -- everything is working as expected. REPLs, aliases, running tests, building uberjars...

works beautifully @delaguardo. Thanks so much!

Thx, good to hear

@delaguardo I'm using your setup for GH Actions on several of my projects so "Thank you!" -- one comment: using tools-deps for the CLI version is a bit confusing since tools.deps is a library with a different version numbering schema -- Clojure CLI 1.10.1.693 uses tools.deps 0.9.799 for example.

I'm just trying to understand the basis stuff, is this intended that :parents of a thing contains a thing itself?

cljfx/cljfx$jdk11 
{:mvn/version "1.7.9"
 :deps/manifest :mvn
 :dependents [cljfx/cljfx$jdk11 cljfx/cljfx]
 :parents #{[cljfx/cljfx cljfx/cljfx$jdk11]
            [cljfx/cljfx]}
 :paths ["C:\\Users\\Vlaaad\\.m2\\repository\\cljfx\\cljfx\\1.7.9\\cljfx-1.7.9-jdk11.jar"]}

(that's an entry in :libs)

you should consider :parents to be undefined for now

in other words, that's internal implementation stuff leaking out and I make no guarantee it will be there or be anything in particular :)

ah, okay. what's not internal there?

everything else

to your original question, I'm not sure why'd you see that though, if you could send me your deps.edn, I'd like to look at it

this is deps.edn: https://github.com/vlaaad/reveal/blob/master/deps.edn

I can reproduce it by using clj without any other args and then loading the basis as described here https://clojure.org/reference/deps_and_cli_prerelease#_basis_injection

(clj on windows, if that matters)

doesn't matter. I look at it's a quirk of how classifier libs work in maven. when you have a lib foo and a classifier jar foo$a they technically both use the same pom. in this case, the root jar depends on the classifier jar, which has the same pom, so it looks like it depends on itself.

so, expected but weird :)

ah, I see, thanks for clarification!

Where might addressing https://clojure.atlassian.net/browse/TDEPS-46 “Repositories from dependencies’ pom.xml are not used” be on the horizon? Any pointers on where one might get started on fixing it?

@alexmiller We haven't seen any impact of the changes to classpath order (yay!) but that made me wonder about pom.xml generation: is the order of the <dependencies> section there important, from a Maven p.o.v.? i.e., does it affect the order things show up on the classpath and does clojure -Spom generate the <dependencies> section in a reproducible order now based on the classpath?

good question. the order is important to maven (you should get deps in the order listed in the pom) and I have not explicitly looked at that ordering wrt deps

so that might be unstable if deployed library is used in a project that uses maven as a build tool?

well, deps.edn takes its deps in a map so from a clj pov, there is no order set by the user (the new changes order by alpha)

@seancorfield if you wanted to file a jira about this, I'd be happy to look at it

Hey, sorry I didn't catch your question earlier in the flow...

I am honestly reluctant to fix this the more I think about it and talk to others about it

There are a lot of security concerns around getting someone's else repository, which may either be an internal repo or a repo that provides rogue versions of deps defined in central repos

So my recommendation right now would be to add those repositories explicitly to your deps/pom instead

Thanks for the feedback! We ran into this today, so I wanted to see what the current thinking on this is. Cheers!

@alexmiller I don't care enough about the issue to file a Jira ticket. I was mostly just curious if you knew off the top of your head whether -Spom generated <dependencies> in the same order as they would now appear on the classpath.

(I didn't care much about the non-reproducible classpath ordering before either -- although some others did)

I looked at the code and the answer is no - they are not necessarily in the same order they'd appear on the classpath