* This is change in behavior, we catch the clojure.core/read-string
exception and we print it to stderr. The difference is that we
let the process continue (e.g. `lein repl` starts) and the previous
behavior was to die (due to the throwing the exception)
* We could mimic the previous behavior by exiting (System/exit 1) on
this exception.
Using clojure.edn/read-string results in nil instead of an exception
user=> (edn/read-string "")
nil
user=> (read-string "")
RuntimeException EOF while reading clojure.lang.Util.runtimeException (Util.java:221)
This addresses the problems seen in #1900 and #1901. It doesn't fix
them because they can't be fixed without breaking other things,
(https://github.com/technomancy/grenchman/issues/34) but at least it
lets people know what is going on and suggests a workaround.
In case network is down while fetching dependencies and we get
NoRouteToHostException exception, fallback to `:offline? true`
behaviour.
Fixes#2054 issue.
When generating a profile scope string for the target path, any subset
of active profiles that matches a composite profile are replaced with
the composite.
For example, the profiles [:base :system :user :provided :dev :foo]
would be represented as "default+foo", because the :default profile is a
composite of [:base :system :user :provided :dev].
This version addresses two Java 9 related issues:
* 0.2.4 would fail under Java 9 if AOT'd
* the latest Java 9 build (9-ea+148) broke dynapath's reflection to make
URLClassLoader modifiable
This switches the default repo url (for resolving artifacts, not
deploying) to point to the CDN-fronted repo. Note that this repo won't
work with Java 6 - users of 6 will need to manually override the default
url to point to the old one (https://clojars.org/repo).
Prior to this commit, profiles with `^:replace` on the dependencies
list would never end up having their dependencies vector normalized
so that it would have `nil` placeholders for the versions of
dependencies that were inheriting their version from `:managed-dependencies`.
This commit normalizes the dependencies vector of a profile during
initialization, to make sure that it will always be normalized.
Since pomegranate mentions that it likes vectors as inputs to its
functions, this commit changes the normalization function to use
`into` instead of `concat`, to make sure that we get a vector instead
of a sequence.
Prior to this commit, if you wanted to use modifiers such as
`:exclusions` or `:classifier` for a dependency whose version you
were managing with `:managed-dependencies`, you would need to
explicitly pass a `nil` as the version string in the dependency
tuple. This commit adds some logic to coerce the vectors before
they are processed, so that if the version string is simply
omitted instead of being set to `nil`, the `nil` will be implicitly
inserted and things will continue to work as before.
This provides a slightly nicer and more intuitive UX for the
managed-dependencies feature.
In certain cases (e.g. reading a project.clj file out of a jar,
rather than from a file on disk) it is useful for the `read`
and `read-raw` functions to support being passed a `Reader` object,
rather than a File or path.
This commit modifies the `read-raw` function to support being
passed a Reader. It also modifies the `defproject` macro to
avoid the assumption that `*file*` will always have a non-nil
value, because that assumption causes an NPE in the case where
a Reader is the source of the project definition.
This commit adds some additional dependencies to the test project
file for managed dependencies, and significantly increases the
coverage of the tests.
This commit deprecates the `resolve-dependencies` function in
favor of `resolve-managed-dependencies`. It also conditionally adds
the `:managed-dependencies` key to the execution of the deprecated
function, in hopes of improving backward compatibility for cases
where people are still calling the deprecated version.
It also cleans up a few docstring "TODO"s and adds real docstrings.
This commit provides initial support for `managed-dependencies`,
where dependency version numbers may be specified in a separate
section called `managed-dependencies`, and those version numbers
will be used for any deps in the main `dependencies` section
that do not explicitly specify a version number.
This is a precursor to being able to specify a "parent" project
that could be used to consolidate version numbers of common
dependencies across a large number of libraries.
