Documentation updates in preparation for 1.4 release.
This commit is contained in:
Phil Hagelberg
parent
5182797f86
commit
89f2a77a7a
7 changed files with 29 additions and 31 deletions
|
|
@ -16,6 +16,8 @@ specifically the <tt>eval-in-project</tt> function. Any code that must
|
|||
execute within the context of the project (AOT compilation, test runs)
|
||||
needs to go through this function.
|
||||
|
||||
TODO: mention eval-in-leiningen
|
||||
|
||||
Leiningen is extensible; you can define new tasks in plugins. Add your
|
||||
plugin as a dev-dependency of your project, and you'll be able to call
|
||||
<tt>lein $YOUR_COMMAND</tt>. See the [plugins guide](http://github.com/technomancy/leiningen/blob/master/PLUGINS.md) for details.
|
||||
|
|
|
|||
4
NEWS
4
NEWS
|
|
@ -1,6 +1,8 @@
|
|||
Leiningen NEWS -- history of user-visible changes
|
||||
|
||||
= 1.4.0 / 2010-??-??
|
||||
= 1.4.0 / 2010-11-??
|
||||
|
||||
* Deprecated :namespaces and :test-resources-path in project.clj.
|
||||
|
||||
* Delete non-project .class files after AOT compilation. (Luc Prefontaine)
|
||||
|
||||
|
|
|
|||
15
PLUGINS.md
15
PLUGINS.md
|
|
@ -10,10 +10,15 @@ To use a plugin, add it to your project.clj :dev-dependencies and run
|
|||
"lein $TASK". If you want plugins to be available for all the projects
|
||||
you use, you can place their jars in ~/.lein/plugins.
|
||||
|
||||
TODO: explain plugin task
|
||||
|
||||
## Writing a Plugin
|
||||
|
||||
Start by generating a new project with "lein new myplugin", and add a
|
||||
leiningen.myplugin namespace with a myplugin function.
|
||||
leiningen.myplugin namespace with a myplugin function. Add
|
||||
:eval-in-leiningen true to your project.clj so Leiningen knows to
|
||||
execute its code inside the Leiningen process rather than spinning up
|
||||
a subprocess.
|
||||
|
||||
Some tasks may only be run in the context of a project. For tasks like
|
||||
this, name the first argument <tt>project</tt>. Leiningen will inspect
|
||||
|
|
@ -35,16 +40,12 @@ your documentation that it only works with Leiningen 1.2.0 and higher.
|
|||
|
||||
The docstring from the plugin's namespace will be displayed by the
|
||||
"lein help" task. The function's arglists will also be shown, so pick
|
||||
argument names that are clear and descriptive.
|
||||
argument names that are clear and descriptive. If you set
|
||||
:help-arglists in the function's metadata, it will be used instead.
|
||||
|
||||
If your task returns an integer, it will be used as the exit code for
|
||||
the process.
|
||||
|
||||
You can set up aliases for your task by conjing a pair of strings with
|
||||
alias->task-name mappings on to the leiningen.core/aliases atom:
|
||||
|
||||
(swap! leiningen.core/aliases conj ["-v" "version"])
|
||||
|
||||
## Lancet
|
||||
|
||||
If your plugins need to do a fair amount of filesystem-y things, you
|
||||
|
|
|
|||
27
README.md
27
README.md
|
|
@ -11,14 +11,8 @@ Leiningen is a build tool for Clojure designed to not set your hair on fire.
|
|||
<img src="http://github.com/downloads/technomancy/leiningen/leiningen-banner.png" alt="Leiningen logo" title="The man himself" align="right" />
|
||||
|
||||
Building Clojure projects with tools designed for Java can be an
|
||||
exercise in frustration. If you use Ant, you end up copying around a
|
||||
lot of the same tasks between XML files on all your projects;
|
||||
there's a lot of repetition. Maven avoids repetition, but provides
|
||||
very little transparency into what's really going on behind the scenes
|
||||
and forces you to become a Maven expert to script a nontrivial
|
||||
build. Either way you must write far more XML than is decent.
|
||||
|
||||
With Leiningen, you describe your build with Clojure.
|
||||
exercise in frustration. With Leiningen, you describe your build with
|
||||
Clojure.
|
||||
|
||||
## Installation
|
||||
|
||||
|
|
@ -59,7 +53,7 @@ project, but here are the commonly-used tasks:
|
|||
|
||||
$ lein test [TESTS] # run the tests in the TESTS namespaces, or all tests
|
||||
|
||||
$ lein repl # launch an interactive REPL session
|
||||
$ lein repl # launch an interactive REPL session and socket server
|
||||
|
||||
$ lein jar # package up the whole project as a .jar file
|
||||
|
||||
|
|
@ -89,9 +83,7 @@ Place a <tt>project.clj</tt> file in the project root like this:
|
|||
:description "A build tool designed to not set your hair on fire."
|
||||
:url "http://github.com/technomancy/leiningen"
|
||||
:dependencies [[org.clojure/clojure "1.1.0"]
|
||||
[org.clojure/clojure-contrib "1.1.0"]
|
||||
[ant/ant-launcher "1.6.2"]
|
||||
[org.apache.maven/maven-ant-tasks "2.0.10"]]
|
||||
[org.clojure/clojure-contrib "1.1.0"]]
|
||||
:dev-dependencies [[swank-clojure "1.2.1"]])
|
||||
|
||||
The <tt>lein new</tt> task generates a project skeleton with an
|
||||
|
|
@ -101,14 +93,11 @@ file for a detailed listing of configuration options.
|
|||
|
||||
You can also have user-level configuration that applies for all
|
||||
projects. The <tt>~/.lein/init.clj</tt> file will be loaded every time
|
||||
Leiningen launches; any arbitrary code may go there. Place jars
|
||||
containing plugins in <tt>~/.lein/plugins</tt> to have them available globally
|
||||
for the current user.
|
||||
Leiningen launches; any arbitrary code may go there.
|
||||
|
||||
You can also use leiningen to manage your plugins with the plugin
|
||||
task. Use the same arguments you would put in the Leiningen
|
||||
:dev-dependencies if you were only using the plugin on a single
|
||||
project.
|
||||
You can also manage your plugins with the <tt>plugin</tt> task. Use
|
||||
the same arguments you would put in the Leiningen :dev-dependencies if
|
||||
you were only using the plugin on a single project.
|
||||
|
||||
$ lein plugin install lein-clojars/lein-clojars "0.6.0"
|
||||
|
||||
|
|
|
|||
|
|
@ -229,6 +229,10 @@ shouldn't have any code with side-effects in the top-level. If you
|
|||
have code that should run on startup, place it in a <tt>-main</tt>
|
||||
function as explained below under "Uberjar".
|
||||
|
||||
TODO: mention javac task
|
||||
|
||||
TODO: mention deletion of non-project .class files
|
||||
|
||||
## What to do with it
|
||||
|
||||
Generally speaking, there are three different goals that are typical
|
||||
|
|
@ -296,6 +300,8 @@ You can run a regular (non-uber) jar with the <tt>java</tt>
|
|||
command-line tool, but that requires constructing the classpath
|
||||
yourself, so it's not a good solution for end-users.
|
||||
|
||||
TODO: mention run task
|
||||
|
||||
### Shell Wrappers
|
||||
|
||||
There are a few downsides to uberjars. It's relatively awkward to
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@
|
|||
(defn install
|
||||
"Download, package, and install plugin jarfile into
|
||||
~/.lein/plugins
|
||||
Syntax: lein plugin install GROUP/ARTIFACT-ID VERSION
|
||||
Syntax: lein plugin install [GROUP/]ARTIFACT-ID VERSION
|
||||
You can use the same syntax here as when listing Leiningen
|
||||
dependencies."
|
||||
[project-name version]
|
||||
|
|
@ -48,7 +48,7 @@ Syntax: lein plugin install GROUP/ARTIFACT-ID VERSION
|
|||
|
||||
(defn uninstall
|
||||
"Delete the plugin jarfile
|
||||
Syntax: lein plugin uninstall GROUP/ARTIFACT-ID VERSION"
|
||||
Syntax: lein plugin uninstall [GROUP/]ARTIFACT-ID VERSION"
|
||||
[project-name version]
|
||||
(let [[name group] (extract-name-and-group project-name)]
|
||||
(.delete (file plugins-path
|
||||
|
|
|
|||
2
todo.org
2
todo.org
|
|
@ -51,8 +51,6 @@ See also http://github.com/technomancy/leiningen/issues
|
|||
the standard lucene index system that Maven repositories offer.
|
||||
This would also mean getting Clojars to produce those indices.
|
||||
* For 1.4
|
||||
** TODO Avoid warning when defining *classpath* by marking :dynamic
|
||||
** TODO get -Xbootclasspath working with Clojure 1.3 again
|
||||
** DONE clear out non-transitive .class files after AOT
|
||||
Luc Prefontaine has code for this.
|
||||
** DONE plugin task for managing/upgrading plugins
|
||||
|
|
|
|||
Loading…
Reference in a new issue