yogsototh/leiningen
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Remove docs for making plugins work with lein 1.x.

Browse source 
[skip ci]
This commit is contained in:
Phil Hagelberg 2017-09-14 12:09:38 -07:00
parent 7a56c0a2aa
commit 45f4365000
1 changed files with 1 additions and 80 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

81
doc/PLUGINS.md
View file

@ -448,30 +448,6 @@ use `eval-in-project` with a dummy project argument:
'(println "hello from" *clojure-version*))
```
## Upgrading Existing Plugins
Earlier versions of Leiningen had a few differences in the way plugins
worked, but upgrading shouldn't be too difficult.
The biggest difference between 1.x and 2.x is that `:dev-dependencies`
have been done away with. There are no longer any dependencies that
exist both in Leiningen's process and the project's process; Leiningen
only sees `:plugins` and the project only sees `:dependencies`, though
both these maps can be affected by the currently-active profiles.
If your project doesn't need to use `eval-in-project` at all, it
should be relatively easy to port; it's just a matter of updating any
references to Leiningen functions which may have moved. All
`leiningen.utils.*` namespaces have gone away, and `leiningen.core`
has become `leiningen.core.main`.
Plugins that do use `eval-in-project` should just be aware that the
plugin's own dependencies and source will not be available to the
project. If your plugin currently has code that needs to run in both
contexts it must be split into multiple projects, one for `:plugins`
and one for `:dependencies`. See the example of `lein-swank` above to
see how to inject `:dependencies` in `eval-in-project` calls.
## Projects vs Standalone Execution
Some Leiningen tasks can be executed from any directory (e.g. `lein repl`).
@ -508,62 +484,7 @@ task will override it. If you'd like to shadow a built-in task, you
can either create an alias or put it in the `leiningen.plugin.compile`
namespace.
## 1.x Compatibility
Once you've identified the changes necessary to achieve compatibility
with 2.x, you can decide whether you'd like to support 1.x and 2.x in
the same codebase. In some cases it may be easier to simply keep them
in separate branches, but sometimes it's better to support both.
Luckily the strategy of using `:plugins` and adding in `:dependencies`
just for calls to `eval-in-project` works fine in Leiningen 1.7.
If you use functions that moved in 2.x, you can try requiring and
resolving at runtime rather than compile time and falling back to the
1.x versions of the function if it's not found. Again the `lein-swank`
plugin provides an example of a compatibility shim:
```clj
(defn eval-in-project
"Support eval-in-project in both Leiningen 1.x and 2.x."
[project form init]
(let [[eip two?] (or (try (require 'leiningen.core.eval)
[(resolve 'leiningen.core.eval/eval-in-project)
true]
(catch java.io.FileNotFoundException _))
(try (require 'leiningen.compile)
[(resolve 'leiningen.compile/eval-in-project)]
(catch java.io.FileNotFoundException _)))]
(if two?
(eip project form init)
(eip project form nil nil init))))
```
Of course if the function has changed arities or has disappeared
entirely this may not be feasible, but it should suffice in most
cases.
Most widely-used functions which have changed in 2.x can be used from
the [leinjacker](https://github.com/sattvik/leinjacker) project, which
provides a compatibility shim supporting both 1.x and 2.x.
Another key change is that `:source-path`, `:resources-path`,
`:java-source-path`, and `:test-path` have changed to
`:source-paths`, `:resource-paths`, `:java-source-paths`, and
`:test-paths`, and they should be vectors now instead of single
strings. The old `:dev-resources` key is now just another entry to the
`:resource-paths` vector that's only present when the `:dev` profile
is active.
Allowing the task to run outside a project directory is tricky to do
in a backwards-compatible way since 1.x is overly-clever and actually
inspects your argument list to figure out if it should pass in a
project argument, while 2.x simply always passes it in and just allows
it to be nil if it's not present. You can try checking the first
argument to see if it's a project map, but if you have more than two
arities this can get very tricky; it may just be better to maintain
separate branches of your codebase in this situation.
### Project-specific Tasks
## Project-specific Tasks
Occasionally, the need arises for a task to be included in a project's
codebase. However, this is much less common than people think. If you