This includes three changes:
* Exclude the dynapath that comes in from bultitude and pomegranate, and
depend directly on a newer version that operates properly under Java 9
* Ensure we have a modifiable classloader before asking pomegranate to
modify it. Before Java 9, the AppClassLoader was a URLClassLoader, and
therefore modifiable. This is no longer the case with Java 9.
* Remove duplicated classpath init code from `eval-in :leiningen`, and
replace it with a call to `project/init-lein-classpath`. This required
making the latter function public.
These changes allow some lein functionality to work under Java 9 - there
is a Java 9 issue with data.xml that needs to be fixed before lein's
tests can all pass (http://dev.clojure.org/jira/browse/DXML-32).
Instead of using String.split then recombining arguments to repair broken
quoted arguments, this parser now finds entire arguments using regex matching.
This is more robust, handling extra whitespace (and non-space whitespace)
correctly, while also correctly matching quotations in argument strings and
preserving internal spaces.
This commit refactors a few things from the `jar` and
`javac` tasks in order to ensure that the "whitelisted"
settings from the user profile (`:local-repo`, `:mirrors`,
etc.) are honored when the `jar` task launches `javac`.
It also adds a test to validate the new behavior.
Passing in the project map as a parameter to eval-in-subprocess causes
havoc, as it has references to the functions reduce-dep-step and
reduce-repo-step in its metadata.
Changes to a native dependency that is not cleaned up will be warned
about to the user. In addition, when a dependency changes, only the
dependencies that actually changed will be checked for native
dependencies, speeding up restart time significantly when you change a
single dependency in a big project.
This fixes the issue with reflection warnings in #2045, but
unfortunately breaks backwards compatibility with 1.1.0. So the lowest
version of Clojure Leiningen now supports is 1.2.0.
Ensures `-XX:-OmitStackTraceInFastThrow` is always included by default
regardless of user's LEIN_JVM_OPTS. This setting can be overridden in
other profiles by the user.
Aliases are higher order, but also attempts to keep track of tasks via
:arglists metadata. The :arglists update function assumed all tasks
would start with a project arg. However, this isn't necessary: A task
may e.g. have the form [& args] and destructure the project arg inside
the function. This caused lein to incorrectly assume that appending more
arguments to the tasks was an error. (The only tasks I know of right now
that does this is mine, so I should probably take the hint)
I also decided to clean up the drop-partial-args function a bit to make
it more readable.
When we expand composite profiles, we may end up with multiple identical
profiles in the resulting list. However, we should only merge a profile
at most once. To fix this, we dedupe the list and retain the _last_
profile mentioned. We retain the last instead of the first as this
prioritises the last profile merges, which is somewhat important for
tasks like repl, uberjar, and to some extent `with-profile +foo`.
It might be interesting to see if we can get away from this in 3.0.0,
for example by saying that
(= (merge-profiles project [:a]) (merge-profiles project [:a :a])).
Fixes#1824 and fixes#2001.
This isn't a perfect solution to error messages, as GPG bypasses the
stdin and sends data directly to the terminal. As such, things from
"stdin" is printed immediately, whereas stderr is printed through the
JVM. As a consequence, it's almost always the case that the stdin lines
are printed before the stderr lines, even though GPG usually sends them
in the opposite order. But it should give you a better indication when
something bad has happened.
Issue #1904 may accidentally be solved as well, as we now have a
shutdown hook on GPG.
If a directory on the classpath does not exist when the JVM is started,
it's ignored even if it is subsequently created. This commit ensures
that source, resource and test paths exist as part of the prep work for
eval-in-project.
Exactly like `sh` except that it requires a failure message and if the
command exits with a non-0 code, it use the failure message to throw an
Exception.
Added unit tests as well.
Upgrade/downgrade are "primitive" tasks that must be implemented in the
shell script for bootstrapping reasons. We have a dummy task just for
the purposes of having somewhere to hang a docstring; this commit adds
the alias for downgrade.
Fixes#1947
Bumping HttpWagon from 2.4 to 2.6 caused old methods in HttpWagon to
disappear, and along with it all the old Apache Http stuff we depended
on. This caused additional CA certificates provided in :certificates to
make Lein just fall on the floor and die.
This bumps HttpWagon to 2.9 and refactors Apache Http usage to
non-deprecated usage for the version we depend on.
Clojure 1.7.0 will add support for reader conditionals:
http://dev.clojure.org/display/design/Reader+Conditionals
This patch adds reader conditional support to leiningen, in particular for
compilation (including aot and stale files) and testing.
The fix is actually very easy: Instead of piping stuff into a reader,
then feed it to *out*/*err* via a writer, we directly hook them to
System.out and System.err.
The problem is that it kills many tests that rely on `with-out-str`, so
we have to include `with-system-err/out-str` macros to catch
sysout/syserr data, and replace usage where tests fail.
It's likely that the alias vector provides additional arguments that
change the semantics of the invocation, so blindly propagating the
docstring would be misleading.
This fixes pass-through-help when used on vector valued aliases. Ex:
:aliases {"a" ^:pass-through-help ["run" "-m" "some.core"]
"b" ^:any-meta ["a"]}
The meta on task b will be `{:pass-through-help true, :any-meta true}`.
This commit adds an extra condition at the beginning of the
`setup-map-defaults` function, such that if one of the two
items being merged has a higher priority than the other,
it is honored.
This seems to fix the issue where the `^:replace` metadata
was not working properly
As described in #1695, the `^:replace` metadata for the
`:repositories` section of the project file stopped working
around 2.4.0 (commit 17e91e6).
This commit adds a failing test that illustrates the
behavior.
The :repl profile does not compose well when specified in both
project.clj and profiles.clj files.
Merge all profiles with ^:repl metadata in the repl task. This allows
multiple profiles to be applied for the repl task.
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).
This allows profiles to set a -Dfile.encoding. Later, perhaps in 3.0,
JVM_OPTS should perhaps be moved farther down the list (along with
:jvm-opts?) -- but that could be a breaking change. (Environment is
sometimes set locally, sometimes set globally.)
Add a raw-read alternative that reads without initializing.
This solves a certain chicken/egg problem with wanting to read profiles
from plugins before the plugins had been loaded.
The :project profile is not un-merged when building a jar or generating
a pom, so can be used to alter the basic layout of a project.
This allows plugins such as cljx and cljsbuild to provide profiles that
the project can choose to use to set source-paths, etc, leading to less
error-prone configuration in common use cases.
Fixes#1665
Unmerge expanded its profiles based on the profiles in the project
map (which don't include :default), rather than profiles in the
:profiles metadata.
The :default keys were also hard coded in the pom generation, so ignored
any additions.
This is in support of https://github.com/lynaghk/cljx/pull/48
Instead of always using a regex to try to match the native-names keys
when doing a get-os or get-arch call, use a get-with-pattern-fallback
function to first try the exact match and only if that fails, use
get-by-pattern. This prevents matching "x86_64" with "x86" when
"x86_64" is the better match.
java.util.JarFile. can fail without reporting the name of the file it's
operating on. If you have a jarfile that isn't a valid zip, this can be
confusing.
