Nice round of bug fixing on t.d.a.! Inspired me to bash a bunch of bugs in clj-new and to cut new releases of depstar and clj-new 🙂

Yep, felt good to do finally

I’m trying to decide if there’s anything left that’s critical before pulling out of alpha

TDEPS-91 ?

I'm a bit surprised that TDEPS-132 isn't fixed by some of the changes in 0.7.516? Or is that just waiting for @dominicm to see what state that ticket should be in with the latest version?

The git stuff is all independent of api. Plenty of things to fix/add still, just don’t think they will affect the api

I haven’t looked at 132, not sure what it needs still

But don’t think it affects api

Ah, OK. Yeah, I guess TDEPS-91 is pure implementation.

What about add-lib at this point?

Will you be updating the add-lib branch from master @alexmiller?

(I'm toying with the idea of doing a screencast of building a small web app from scratch but was thinking of using add-lib to show how to add dependencies while you're working live in an app... thoughts?)

add-lib is additive so, wouldn’t affect alpha. Not sure yet where that will go

I can update add-lib if you need it, although it’s not far behind master

It would be nice to keep it current with each release "just because" 🙂

updated, new sha d0b33e0d346736aa985c150145b332f97b92135e

Thank you!

My dot-clojure repo is updated to use that SHA for :deps.

Not sure when I'll do the add-lib screencast. I'll probably try to find time this week.

This "Bill of materials" from maven is not existent on tools-deps because it already compute the transitive dependencies rightly ? Is it like a in advanced package-lock.json ?

@geraldodev Not quite sure what you're asking there?

With Maven, each library lists only what it depends on directly -- and then Maven figures out all the transitive dependencies...

https://stackoverflow.com/questions/27100141/what-is-bill-of-materials-coming-in-spring

I'm trying camunda-bpm and it has a bill of materials artifact

on mvnrepository it advises to import into lein like this [org.camunda.bpm/camunda-bom "7.11.0" :extension "pom"]

Just read that, still no idea what it is that's any different from specifying dependencies...

deps.edn supports :extension

seanc@DESKTOP-QU2UJ1N:~/clojure$ clj -Sdeps '{:deps {org.camunda.bpm/camunda-bom {:mvn/version "7.11.0" :extension "pom"}}}'
Downloading: org/camunda/bpm/camunda-bom/7.11.0/camunda-bom-7.11.0.pom from 
Downloading: org/camunda/camunda-release-parent/3.3/camunda-release-parent-3.3.pom from 
Downloading: org/camunda/bpm/dmn/camunda-engine-dmn-bom/7.11.0/camunda-engine-dmn-bom-7.11.0.pom from 
Downloading: org/camunda/commons/camunda-commons-bom/1.7.1/camunda-commons-bom-1.7.1.pom from 
Downloading: org/camunda/connect/camunda-connect-bom/1.1.4/camunda-connect-bom-1.1.4.pom from 
Downloading: org/camunda/spin/camunda-spin-bom/1.6.7/camunda-spin-bom-1.6.7.pom from 
Downloading: org/camunda/template-engines/camunda-template-engines-bom/1.1.0/camunda-template-engines-bom-1.1.0.pom from 
Downloading: org/camunda/camunda-release-parent/3.0/camunda-release-parent-3.0.pom from 
Clojure 1.10.0

The right way of using this camunda-bom

I thought there was a syntax involving $ for classifier support but this seems something different (simpler).

what :extension "pom" does ?

Ah, here you go: https://clojure.org/reference/deps_and_cli#_dependencies -- that describes :extension (as above) and the $ syntax for classifiers.

I don't know much about Maven but my understanding is that :extension "pom" tells the system to look for a .pom file instead of a .jar file -- which is what you need for BOM, right?

From what I understood this bom is a dependency that its like a package-lock.json and later the artifact is enlisted as a dependency minus its version, and maven uses this blessed list to fetch the right version

I've no idea what a package-lock.json file is, BTW.

if you clj -Stree '{:deps {org.camunda.bpm/camunda-bom {:mvn/version "7.11.0" :extension "pom"}}}'|grep camunda camunda its not listed, so I assume it's not being seen like a dependency

@seancorfield thx helping me. I'll no use the BOM artifact.

Yeah, so it looks like you'd have to specify all the camunda deps explicitly in deps.edn if pulling in via the bom doesn't work...

@alexmiller can probably explain more of the differences between how lein/`boot` work and how tools-deps works around that.

even there I think its not automatic because there is a https://github.com/tsachev/lein-bom plugin

Ah, interesting. Maven is a giant mystery to me and I try hard to avoid it as much as possible 🙂

me too, but I'm trying to use camunda-bpm-engine on a tools-deps project