Fork me on GitHub

Any advice on troubleshooting dependency ordering issues in my app? The namespace ordering seems to be pretty clear, but mount is starting one defstate prior to a defstate it depends on and the app is failing. When I run (graph/states-with-deps) it reflects the order I'm seeing and interestingly all of the deps sets are empty. A couple of notes: this is when running tests with lein and some of the defstates are in a dependency jar. I realize this is kind of vague, just wondering if anyone can give pointers for best practices on troubleshooting...


@manderson is that problematic dependency a part of your app logic or some generic library? because it's not recommended to put defstates into libraries. i remember this was mentioned in either some mount documentation or in one of the articles on tolitius' blog but i can't find the reference now. it was explained there why.


The dependency is my own and part of my app (the app is made up of several sub-modules with some generically useful code in the dependency jar). I'll take a look around to see if I can find the article. I was actually able to get this working by pulling my test namespace out into its own sub-module. Still not sure what the source of the problem was, but I'm at least unblocked for now. Thanks for the response.


@manderson: it would all of course depend on what depends on what (the way compiler thinks about it), especially if you have defstates living inside of the modules (which brought in as jars) you have a class loader dimension as well.. but one way to work with unpredictable dependency order would be to simply do:

(mount/start #'a/state #'b/state)
which will ensure that a/state and b/state start first, before anything else, and then everything else will follow. (mount/start ...) will check whether the state is already started, so a/state and b/state won't be started twice.


Cool, thanks @tolitius. I did suspect it could be an issue with classloaders/aot/etc. I didn't know about the separate mount/starts. That's helpful.