is there an example out there how to do mixed java + clj projects with deps?

@ikitommi AFAIK tool.deps doesn't support java compilation. Only way I know to get around it is build the java project separately and import it as a dep in deps.edn.

thanks, but that was not the answer I was hoping for.

I messed around with JNI stuff and deps.edn but basically did the compiling myself through a Makefile, probably not helpful but still. https://github.com/Olical/snowball

yeah I had asked about it a while back and got the answer. compiling java is beyond tools.deps scope i think and it makes sense

My two suggestions are either to use an additional build tools around clj or to wall off your Java bits in their own project with their own artifact build

haven't tried the following yet, but it looked promising: https://github.com/EwenG/badigeon

@ikitommi you could always cheat and use the -e option to run clojure.java.sh and shell out to the Java compiler 😇😂🤪

great idea Sean 😉 did a external compile for my case, but puzzled that has the idea been that people would start using deps instead of boot or lein? Still need a “do-it-yourself” build tool on top - not the most welcoming newbie experience. Some official lein’ish battery-pack would be great?

newbies don't want to compile java 🙂

but battery-pack is something we've talked about

badigeon can indeed compile java, let me know if you have any issue with it

I am about to try out badigeon myself for compiling some protobuf java classes

@ikitommi Given how many beginners I've seen get tripped up with ~/.lein/profiles.clj in the last few months, I think there's a good argument for simpler tooling like the Clojure CLI. I've seen beginners struggle a lot less with the CLI than you might think.

And, yes, as @ghadi says, "newbies" aren't trying to compile Java and Clojure together.

At work, we do everything with the CLI and a small handful of (sharp) tools. We have a shell script purely to automate repeated sequences of clojure invocations.

@ikitommi in pack.alpha I do some clever stuff to compile java using the JDK api. Not much better than shelling out 🙂

I have toyed around with the idea of using the ztellman library for reloadable java with tools.deps but never actually done it.

@alexmiller circling back - the problem goes away if I supply a ClojureScript git dep version in the root project. Is the behavior I observed yesterday a bug, or just the current behavior? if I supply all the exclusions should I be able to avoid the warning about comparing versions?

not sure

walking the full deps tree necessarily requires comparing versions of things, and comparing mvn to git is not (yet) supported (although I know how to do it)

the question is whether in this particular scenario, with exclusions, the comparison can be avoided. exclusions are tricky and it's hard for me to answer that question without having the full scenario in hand.

k

@alexmiller ok when I made a minimal case :exclusions worked for me - so I guess -Stree can't be used reliably?

hrm I guess perhaps a comparison happens before you know it will be excluded?

yes, and as you encounter more things, it's possible for the excluded state of something to change

verbose output just seems to confirm that my exclusions worked

but the end behavior is surprising

-Stree tells you the end state, but is not the whole story of how it got there

since for the end user this doesn't seem deterministic

sometimes exclusions work

sometimes it doesn't

it also breaks using git deps transitively

yes, there is a ticket in this area (specifically around cljs iirc, although not with a git dep)

it can't be done safely

so you have to re-declare your deps at the bottom

I think you are jumping to conclusions that are not necessarily true

so you have some way to avoid the above?

I have to re-declare my git deps right now

it is possible to declare deps trees that are either logically inconsistent (impossible to satisfy the deps and exclusions as stated across the tree) or that are ambiguous

but that's not what I've described above

well you haven't given me a repro, so I can say either way

yeah I don't know how make this one since it's non-trivial project with non-trivial deps

it works in the trivial case

most things do :)

... oh

other git stuff won't appear in -Stree?

-Stree should be the full tree of everything chosen at the end (it's just the inverted lib map which you can find in the .cpcache in the .lib file)

so other git stuff will appear there

it does not list things that were children but not chosen (due to exclusions or version selection or being dominated by a top dep)

ah

sorry, I have to run to the dentist

one second maybe I see a way to repro now

k, will drop a link to something minimal if I can make it

I found the issue which arose from a misunderstanding on my part

I had a project which delcared a ClojureScript dep - and of course there were transitive deps that also declared ClojureScript but no conflicts because I guess clj considers the deps.edn :deps to be overrides?

once I was using that project transitively - those became conflicts

I had removed the conflicts from the downstream project, but not this upstream one

On your question above about overrides, I’m not sure what you mean but I suspect you’re making up a model there. Top level deps are always taken as overriding decisions of the transitive deps

that's what I meant

When you move to your “upstream” project though, the deps of the “downstream” project are no longer top deps

"top-level"

So are subject to other selections

yeah that was the model I came up w/ based on what I saw

so good to hear that confirmed