In this article we will first look at how to define a dependency description. If we often maintain the base repository of the main project, we will often encounter that the effect of the modification cannot be well verified after modifying the repository. Either we will embed the repository project as a separate Git submodule into the business project, or we will simply comment out the online dependencies and add the path of the local repository.

So is there a good way to seamlessly switch between local source dependencies and online dependencies?

For Android, you can use Gradle to download binary files from Maven or JCenter. For Android, you can use Gradle to download binary files from Maven or JCenter. So how to implement the dependency repository file on the Android platform?

The dependency manager probably consists of several parts, dependency description files, publication specifications, and so on. Dependency description files vary in format from dependency manager to dependency manager: Json, XML, DSL, and so on. When the project has dozens of dependencies Json XML simply cannot be looked at. Although DSL is weak in the expression of the project structure, it has obvious advantages in readability. Cocoapods uses this expression. Very beautiful, as follows.

Platform: ios, '8.0' use_frameworks! Target 'MyApp' do pod 'AFNetworking', '~> 2.6' pod 'ORStackView', '~> 3.0' pod 'SwiftyJSON', '~> 2.3' endCopy the code

Looking at this dependency description, the mood will be much better.

Can you do something similar on Android? Android is built in Groovy, and Groovy supports DSLS pretty well, so you can use groovy’s DSL features to describe dependencies that you think are a description, but are actually an executable script.

We need a description of the module, including switch, name, path, etc., like the following:

Module {on_off true name "path" /path"}Copy the code

Ok, how do I implement this once I have the definition?

For example, module can be a function, and its parameters are a closure. Similarly, on_OFF, name, etc., are function calls, and the parameters after the function are function parameters.

Isn’t that interesting? A sentence can be executed as a script.

So, we need to define the function we want to use in our dependency description, as follows:

class Module { boolean on_off String name String path void on_off(boolean on_off) { this.on_off = on_off println("module  on_off:" + on_off) } void name(String name) { this.name = name println("module name:" + name) } void path(String path) { this.path = path println("module path:" + path) } } Module module(@DelegatesTo(strategy = Closure.DELEGATE_FIRST, value = Module) Closure script) { script.resolveStrategy = Closure.DELEGATE_FIRST Module module = new Module() script.delegate = module script() return script.delegate }Copy the code

The function named Module receives a closure. The closure proxy is the Module class. The function inside the closure automatically performs the proxy function call. Write the following DSL life under the defined classes and functions, execute.

Module {on_off true name "I am a name" path "I am a path"}Copy the code

Module on_off:true module name: I am the name module path: I am the path

It looks like the DSL we defined has been successfully resolved.

The dependency description has been defined, and the next article will show how to dynamically generate the dependency description file.

Repository source dependency Manager (2)