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

Improve coverage of profiles in tutorial and profiles doc.

Browse source
This commit is contained in:
Phil Hagelberg 2013-08-12 17:15:40 -07:00
parent 81389cf20c
commit 4b099af5d1
2 changed files with 27 additions and 7 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

10
doc/PROFILES.md
View file

@ -7,10 +7,10 @@ without including them in the jar, or you may want to have Slamhound
available in every project you hack on without modifying every single
project.clj you use.
By default the `:dev`, `:provided`, `:user`, and `:base` profiles are
activated for each task, but their settings are not propagated
downstream to projects that depend upon yours. Each profile is defined
as a map which gets merged into your project map.
By default the `:dev`, `:provided`, `:user`, `:system`, and `:base`
profiles are activated for each task, but their settings are not
propagated downstream to projects that depend upon yours. Each profile
is defined as a map which gets merged into your project map.
You can place any arbitrary `defproject` entries into a given profile
and they will be merged into the project map when that profile is
@ -38,6 +38,8 @@ that you don't want committed in version control.
User-wide profiles can also be specified in `~/.lein/profiles.clj`. These will be
available in all projects managed by Leiningen, though those profiles will be
overridden by profiles of the same name specified in the project.
System-wide profiles can be placed in `/etc/leiningen`. They are treated
the same as user profiles, but with lower precedence.
You can also define user-wide profiles within `clj`-files inside
`~/.lein/profiles.d`. The semantics within such files differ slightly

24
doc/TUTORIAL.md
View file

@ -429,6 +429,24 @@ from missing functions (often referred to as "getting
slimed"). Because of this it's advised to do a `lein test` run with a
fresh instance periodically in any case, perhaps before you commit.
## Profiles
Profiles are used to add various things into your project map in
different contexts. For instance, during `lein test` runs, the
contents of the `:test` profile, if present, will be merged into your
project map. You can use this to enable configuration that should only
be applied during test runs, either by adding directories containing
config files to your classpath via `:resource-paths` or by other
means. See `lein help profiles` for more details.
Unless you tell it otherwise, Leiningen will merge the default set of
profiles into the project map. This includes user-wide settings from
your `:user` profile, the `:dev` profile from `project.clj` if
present, and the built-in `:base` profile which contains dev tools
like nREPL and optimizations which help startup time at the expense of
runtime performance. Never benchmark with the default profiles. (See
the FAQ entry for "tiered compilation")
## What to do with it
Generally speaking, there are three different goals that are typical
@ -582,9 +600,9 @@ project's full test suite, and if it passes, upload a tarball to S3.
Then deployment is just a matter of pulling down and extracting the
known-good tarball on your production servers.
Also remember that the `user`, `dev`, and `default` profiles are
included by default, which is not suitable for production. Using
`lein trampoline with-profile production run -m myapp.main` is
Also remember that the default profiles are included unless you
specify otherwise, which is not suitable for production. Using `lein
trampoline with-profile production run -m myapp.main` is
recommended. By default the production profile is empty, but if your
deployment includes the `~/.m2/repository` directory from the CI run
that generated the tarball, then you should add its path as