Fork me on GitHub

one can use xmllint as well for getting the version out like here: but setting it probably mvn plugin like @alexmiller does in the release script.

lread14:09:44 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.

šŸ‘ 1

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
Somehow it bothers me how long it takes maven to do this thoā€¦


anyone tried the clj prerelease yet?


I havenā€™t, but Iā€™d like to do it today


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


Thx, good to hear


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

{:mvn/version "1.7.9"
 :deps/manifest :mvn
 :dependents [cljfx/cljfx$jdk11 cljfx/cljfx]
 :parents #{[cljfx/cljfx cljfx/cljfx$jdk11]
 :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


I can reproduce it by using clj without any other args and then loading the basis as described here


(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!

delaguardo15:09:12 btw, github action support prerelease as well. Might make the way to try it a little bit easier šŸ˜„


works beautifully @delaguardo. Thanks so much!


@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 uses tools.deps 0.9.799 for example.


thanks for the feedback! I made a PR to address that confusion: how do you think about it?


That looks good!


merged, thanks again for pointing on that


Where might addressing ā€œRepositories from dependenciesā€™ pom.xml are not usedā€ be on the horizon? Any pointers on where one might get started on fixing 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 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


@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