This one needs a little more thought, so I'm going to pull it out of 0.4.0 scope.

Pinging @grzm since he was interested in deps.edn support when I gave my talk to Clojure.mn.

Options

Direct tools.deps

We can just directly use tools.deps, but the major downside is that it won't play well with any other dependencies you add to the build.gradle. It won't participate in any of Gradle's normal dependency resolution schemes, so some unexpected things could happen.

Maybe the behavior here would be, if you use tools.deps directly, we blow up if you add dependencies to Gradle directly.

Direct use of tools.deps is my least favorite option, though I see the benefit in trying out Gradle without having to convert things.

Mimic tools.deps

The more complicated option... Instead of using tools.deps directly, implement its behavior to read deps.edn from the same locations it does and then load those dependencies into the Gradle model.

Reading the deps.edn format
Merging the various locations
Translating maven deps to Gradle maven deps
Translating overrides and defaults to Gradle resolution rules
Implementing support for git, local, etc.

Library to support an build.gradle generation like -Spom

Support something like an -A:gradle to generate a build.gradle from a deps.edn. Look at tools.deps.alpha.gen.pom for how the native -Spom feature is implemented.

Merging with an existing build file would be tricky though.

(Tangential) Library to add a :gradle provider, like the `:pom`

You can provide a :pom entry in your :deps map, which allows you to pull in a project that uses Maven. It might be nice to similarly pull in a local Gradle project with a :gradle entry in your :deps.

Might require running Gradle (maybe via the Tooling API) to interact with the model and determine the dependencies, source locations, etc.

Mapping to Gradle configurations

The standard deps map, would be your main sourceSets compile dependencies.
The test alias would be your test sourceSets compile dependenices.
The dev alias would be your dev sourceSets compile dependencies.

I feel like we should prevent adding dependencies to main (and maybe test) from the user or installation deps.edn files. Those are just a recipe for un-reproducible builds. It makes sense to add them for dev I think.

Aliases

Is there any need for alias support in Gradle (besides using test and dev)?

deps.edn support #58

Description

Activity

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions