> 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.
