Fork me on GitHub
#tools-deps
<
2020-09-23
>
timo09:09:42

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.

lread14:09:44

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.

šŸ‘ 1
lread14:09:21

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ā€¦

alexmiller15:09:08

anyone tried the clj prerelease yet?

vlaaad16:09:25

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

seancorfield16:09:10

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

alexmiller16:09:43

Thx, good to hear

vlaaad18:09:13

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"]}

vlaaad18:09:41

(that's an entry in :libs)

alexmiller18:09:31

you should consider :parents to be undefined for now

alexmiller18:09:16

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

vlaaad18:09:07

ah, okay. what's not internal there?

alexmiller18:09:17

everything else

alexmiller18:09:30

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

vlaaad19:09:58

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

vlaaad19:09:13

(clj on windows, if that matters)

alexmiller19:09:50

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.

alexmiller19:09:03

so, expected but weird :)

vlaaad19:09:04

ah, I see, thanks for clarification!

delaguardo15:09:12

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

ghadi16:09:10

works beautifully @delaguardo. Thanks so much!

seancorfield17:09:37

@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.

delaguardo08:09:57

thanks for the feedback! I made a PR to address that confusion: https://github.com/DeLaGuardo/setup-clojure/pull/13/files#diff-cdc05b01d72867060bc4d72cb108cf25 how do you think about it?

seancorfield15:09:08

That looks good!

delaguardo15:09:52

merged, thanks again for pointing on that

grzm20:09:09

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?

alexmiller21:09:22

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

alexmiller21:09:05

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

alexmiller21:09:28

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

alexmiller21:09:52

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

grzm22:09:03

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

seancorfield20:09:11

@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?

alexmiller21:09:27

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

vlaaad21:09:51

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

alexmiller21:09:07

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)

alexmiller21:09:50

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

seancorfield22:09:19

@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.

seancorfield22:09:44

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

alexmiller22:09:55

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

1