We've moved to a model where we AOT only those namespaces that need to result in "Java classes" and we resolve into the main code at runtime for the implementation. We have all the AOT "shims" in one project and everything in non-AOT projects. That allows us to essentially ignore AOT except for the very thin interface Java imposes on our code - and we can work in the REPL with nearly all our code and test-drive it etc using a regular Clojure workflow.
Only when the shim actually changes do we need to run `lein install` to AOT compile & install an updated JAR, then restart our main project REPL to pick up that API change. Since the implementation is require'd and resolve'd in at runtime, it can change as much as we want in the meantime. On Aug 11, 2014, at 2:13 PM, Brian Craft <craft.br...@gmail.com> wrote: > A number of clojure tools, like tools.namespaces, and codox, don't work with > aot compiling, and their docs say to turn it off. However aot compiling isn't > really optional: we're embracing the platform, and java libs like their named > classes. > > How do you work around this? I can move aot compiling to the uberjar target, > but then I can't work on the system from the repl, because it can't be > launched. The java libs won't find the classes they need.
signature.asc
Description: Message signed with OpenPGP using GPGMail
