Don't call set-profiles from leiningen.core.project/read because it
calls load-middleware, and we want to wait to do that for the first time
in init-project. To solve this, I added init-profiles which is called by
both read and set-profiles.
Also clean up init-project and move code duplicated in set-profiles into
activate-middleware. We now always load hooks and certificates when
activating middleware, and load-certificates is actually called twice in
the course of init-project. To make sure load-certificates is
idempotent, we memoized leiningen.core.ssl/register-scheme.
Both now expect a full var, though hooks will fall back to activate in
the provided namespace for compatibility.
Also, use the following convention for plugin auto hooks and middleware:
- Assuming your plugin is called lein-config
- Put hooks you want auto-loaded in lein-config.plugin/hooks
- Put middleware you want auto-applied in lein-config.plugin/middleware
Previously, you could not unmerge composite profiles. So, if the
currently active profiles were [:default], which is a composite of
[:dev :user :base], then (unmerge-profiles project :dev) would do
nothing. To fix this, we have to keep track of both :included-profiles
and :excluded-profiles.
I also combined apply-profiles and reset-profiles into a single function
called reset-profiles with an optional excluded-profiles argument and
renamed apply-profiles-raw to apply-profiles.
Any dependency marked with :ext true will be loaded by the ext class loader.
Libraries with native dependencies (e.g. tokyocabinet) need to be loaded by
the ext classloader, because native libraries can only be loaded once per
JVM. Also, most SQL libraries (e.g. postgresql) need to be in the ext class
loader because java.sql.DriverManager holds onto the class.
Use 0.6.6 classlojure's alter-java-library-path! to set java.library.path
at runtime.
Perhaps we should be setting all of these system properties back after
we are done, including this one?
