Sean Corfield, Thanks for this. I can go through my code and try to remove all of the uses of JodaTime in my own code, but, as that would be some work, I'd like to first confirm the diagnoses. Can you think of a way I might be able to confirm that Joda is, in fact, the problem?
---- lawrence On Monday, June 29, 2015 at 8:59:35 PM UTC-4, Sean Corfield 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, gingers...@gmail.com <javascript:> 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 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.
