Prior to this commit, if you wanted to use modifiers such as
`:exclusions` or `:classifier` for a dependency whose version you
were managing with `:managed-dependencies`, you would need to
explicitly pass a `nil` as the version string in the dependency
tuple. This commit adds some logic to coerce the vectors before
they are processed, so that if the version string is simply
omitted instead of being set to `nil`, the `nil` will be implicitly
inserted and things will continue to work as before.
This provides a slightly nicer and more intuitive UX for the
managed-dependencies feature.
This commit clarifies some things in the docs based on PR review.
It also adds additional test coverage for managed dependencies;
specifically, a case where two normal dependencies both have
a transitive dependency on the same library, but with different
versions. The test validates that this conflict is properly
resolved via `:managed-dependencies`.
The documentation said to "Create a file called `src/myplugin/profiles.clj`". This didn't work for me. I had to create a file `resources/myplugin/profiles.clj` instead.
There was a file handle leak in the code as it was. It would never close the open reader against the jar resource. This will eventually cause JVM to be unable to open new files.
Functional Tests
----------------------
I'm using the code as I wrote it in my own project and there is now no file handle leak.
While trying to develop a Leiningen plugin I stumbled over two small
things, which I think make other people stumble as well:
- Adding the path to my plugin's src directory to .lein-classpath
didn't help anything. Leiningen still loaded the coded that I had
installed to the Maven repository and ignored the local changes.
Putting :provided or :resolve or :classpath after the plugin
coordinates as suggested in issue #750 didn't help either. After
banging my head against this, I got the idea to remove the plugin
entry completely and it worked. Not sure if this is the intended
behaviour, though. Add a step-by-step guide to getting what you want
anyway.
- It wasn't at all clear to me how to do the subtasks thing. The
sentence about the :subtask metadata is a bit garbled and I thought
there might be a mechanisms that invokes subtasks for me. I couldn't
find anything about that, though. A quick search took me to
https://github.com/devth/lein-worker/blob/master/src/leiningen/worker.clj,
which showed the relevant bits. Add an example, because that's what
people understand.
Discussion:
- The new place of the paragraph for emitting output is not very good,
but it's better than leaving it at the bottom of the newly expanded
local development section, where nobody would see it.
- Renaming "Documentation" to "Documentation and subtasks" is a rather
thin patch. – Instructions on how to invoke subtasks don't really
belong in a section about documentation. – However, I'm too lazy to
do a lot of restructuring and I think people will still find what
they're looking for.
