Also, your last error (about in-ns) is from an incompatible version of clj-time, not joda-time.
By the way, this has nothing to do with interop, it's straight dependency management on the jvm. Concerning FD's solution of classloaders, you'll also jave to figure out a way to package the different versions into your JAR, which will not be trivial if both versions use the same package names (which seem to be the case). I think your best bet at this point is to carefully read the lein deps :tree output to note all of the required versions of clj-time and jodatime, and then try to play with either excludes or version ponning in your project.clj until you find a combination that works. Also remember that your code is the most flexible: are you absolutely stuck using clj-time 0.6.0 for your own code ? On Tuesday, 30 June 2015, Sean Corfield <s...@corfield.org> wrote: > Have you actually tried any of the exclusions that Leiningen suggests? For > example: > > [clj-time "0.6.0"] > overrides > [ring "1.4.0-RC1"] -> [ring/ring-jetty-adapter "1.4.0-RC1"] -> > [ring/ring-core "1.4.0-RC1"] -> [clj-time "0.9.0"] > and > [ring "1.4.0-RC1"] -> [ring/ring-devel "1.4.0-RC1"] -> [ring/ring-core > "1.4.0-RC1"] -> [clj-time "0.9.0"] > and > [ring "1.4.0-RC1"] -> [ring/ring-core "1.4.0-RC1"] -> [clj-time "0.9.0"] > > Consider using these exclusions: > [ring "1.4.0-RC1" :exclusions [clj-time]] > [ring "1.4.0-RC1" :exclusions [clj-time]] > [ring "1.4.0-RC1" :exclusions [clj-time]] > > This tells you to that Ring is pulling in the later version of clj-time > (and, hence, the Joda Time 2.6) but clj-time 0.6.0 is pulling in 2.2 (next > set of suggested exclusions). The suggestion is to add the exclusions to > your Ring dependency: > > [ring "1.4.0-RC1" :exclusions [clj-time joda-time]] > > See if that helps. > > Sean > > On Jun 29, 2015, at 5:17 PM, gingersafflo...@gmail.com > <javascript:_e(%7B%7D,'cvml','gingersafflo...@gmail.com');> wrote: > > > > If the worst comes to the worst, you may need to run the NLP module > > and the Clojure code in separate JVMs using some form of IPC to exchange > data. > > That is what I'm looking at right now, though I've also been told that I > absolutely must have this working by tomorrow morning, so I'm a little > frustrated with the amount of work I face tonight. Also, a month ago we > were doing IPC and then we gave up on that redesigned the NLP to work as a > library we could embed inside of the Clojure app, but now it looks like we > need to reverse that decision. > > For me, it's been a good reminder that "easy Java interop" is true up to a > point, but then very not true for certain kinds of ambitions. > > > > On Monday, June 29, 2015 at 7:18:07 PM UTC-4, Fluid Dynamics wrote: >> >> On Monday, June 29, 2015 at 6:38:40 PM UTC-4, Gary Verhaegen wrote: >>> >>> Assuming there is a version that works for both dependencies, you can >>> manually fix it in your own project.clj. Your own direct dependencies >>> will override transitive ones. >>> >>> Otherwise, as far as I can tell, you're stuck. Maybe you can try using >>> an older clj-time? >>> >> >> In theory, JodaTime 2.6 should not have any API-breaking changes since >> 2.1, or they should have called it 3.something. >> >> So, if you can force the NLP module to use JodaTime 2.6 it *should* work. >> >> If that fails, it may still be possible if you can force the two versions >> of JodaTime to load in separate classloaders. I haven't the foggiest how >> that might actually be achieved. Actually I'm somewhat surprised that the >> Java NLP component and clj-time are not *already* loading in different >> classloaders, the former in the standard Java classloader and the latter in >> Clojure's DynamicClassLoader. Two different versions of the same Java >> package or Clojure namespace can *usually* coexist peacefully in different >> classloaders, though, modulo native dependencies or centralized filesystem >> stuff (e.g. a single .foo file in the user directory that they both modify, >> stepping on each others' toes, and they can't be overridden to look for >> separate files to each keep their own version). >> >> If the worst comes to the worst, you may need to run the NLP module and >> the Clojure code in separate JVMs using some form of IPC to exchange data. >> Then deployment, startup, and shutdown become more complicated and >> annoying, and communication across the divide much less efficient (like >> kernel mode switching, IPC means carting data across address space >> boundaries), so ideally there'd be a clean internal boundary between the >> NLP-parts and the rest that has relatively little traffic crossing it. >> You'd then end up with a kind of NLP daemon and an application that had a >> dependency on it. >> > > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > <javascript:_e(%7B%7D,'cvml','clojure@googlegroups.com');> > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > <javascript:_e(%7B%7D,'cvml','clojure%2bunsubscr...@googlegroups.com');> > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com > <javascript:_e(%7B%7D,'cvml','clojure%2bunsubscr...@googlegroups.com');>. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
