Closed ikitommi closed 9 years ago
Yeah, the current behavior is not optimal, for sure. I'm not a huge fan of the ./
namespace - I'm still trying to decide what the optimal path is, though at the moment I'm leaning towards a solution like #7. In the near-term you can disable the java support by setting :java false
in your :ultra
map.
This is on my roadmap for 0.2.0 so hopefully I'll have a proper fix out soon.
Thanks, but I have the :java false
already. Midje seems to conflict with those, simple way to test:
lein new compojure-api ultra +midje
cd ultra
lein midje
gives out:
WARNING: protocol? already refers to: #'clojure.core/protocol? in namespace: potemkin.types, being replaced by: #'potemkin.types/protocol?
WARNING: protocol? already refers to: #'clojure.core/protocol? in namespace: potemkin.collections, being replaced by: #'potemkin.types/protocol?
All checks (2) succeeded.
more likely to come from [prismatic/plumbing "0.3.7"]
. Uses potemkin under the hoods. So, running this test gives the warning (and removing the plumbing removes it):
(ns kikka.core-test
(:require [midje.sweet :refer :all]
plumbing.core))
(fact "plus"
(+ 1 1) => 2)
I'm sorry, I didn't follow your last two comments. Are you saying that you think the warning is coming from Midje + Potemkin colliding with each other?
FWIW, I believe most cases in which Ultra was responsible for such warnings should be resolved with today's release (0.2.0). I'm going to close this issue, but please let me know if the new update doesn't resolve the problem for you.
problem was with Ultra, when used with Plumbing & Midje. Fixed in 0.2.0
, thanks!
There seems to a clash with potemkin Vars with my setup (using Vinyasa):
what if Ultra would inject Vars into custom & configurable namespace like Vinyasa does (defaulting to
./
), instead of adding stuff toclojure.core
=> would separate nicely the things "available in the dev repl" and "available in the installed prod".thanks for the awesome tool.