We run into this sort of thing quite a bit. Our solution so far has been:
1. Always use `:pedantic? :abort` in the project file. It can be annoying,
but we've found that's much better to get annoying errors about version
conflicts at build time than to get cryptic failures at runtime, such as
Hi,
Thanks for your responses. I will go and try the :provided profile and see
how it works out.
Thanks,
Sven
Am Samstag, 9. April 2016 02:51:15 UTC+2 schrieb Daniel Ziltener:
>
> Hi Sven,
>
> When you're sure the project depending your library does also has a
> dependency on a third library,
Hi Sven,
When you're sure the project depending your library does also has a
dependency on a third library, it's best to use the ":provided" profile,
rather than declaring it in the :dev profile. In your case there are two
possible solutions:
1. the dependency higher up wins. So if you declare
Include it as a dependency.
Maven dependency resolution is rather strange, and Leiningen inherits this
strangeness. Effectively what matters is how "close" the dependency is. So
dependencies in your project file take precedence over the dependencies of
your dependencies, and so forth.
Maven does
Hi,
I have a library A that I use in project B. Now, library A makes use of
plumatics schema, as well as project B. I wonder what the best practice is
here.
Include schema in library A's dependencies? Or only declare a
dev-dependency on schema in library A?
If I declare a dev-dependency I req
