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.
GPG.md.
I only write the solution in GPG.md because there is a leiningen message
See `lein help gpg` for how to install gpg.
reading troubleshooting section in GPG.md should be enough to find the solution.
Adds :leaky and :pom-scope metadata for profiles. The :dev, :test,
:base and :provided profiles are implemented in terms of these.
Profiles with :leaky metadata affect the pom and jar creation.
Profiles with a :pom-scope metadata of :test or :provided also affect
the dependencies of a pom.
We need to revisit this in a way that doesn't involve hard-coding
profile names into the jar and pom tasks. The question of whether the
profile should be visible to downstream consumers should be determined
by data that's part of the profile (or metadata).
