Skip to content
This repository has been archived by the owner on Apr 25, 2024. It is now read-only.

Hacking the plugin

Alexander Yakushev edited this page Jul 24, 2015 · 11 revisions

This documents explains how to setup an environment where you can modify lein-droid, experiment with it, implement new features, fix bugs etc.

Code layout

leiningen.droid is a facade namespace for all other lein-droid subtasks. It is responsible for adding different defaults to the project map by calling leininingen.droid.utils/android-parameters, before it passes the project map to the subtasks.

leiningen.droid.aar contains functions that operate on AAR archives. AAR is a special packaging format for Android libraries that combines compiled code and resources. Lein-droid must first unzip AAR dependencies before they can be used.

leininged.droid.classpath initializes several hooks that modify Leiningen behavior in certain ways. For example, there is a hook that adds a proper android.jar to the classpath every time get-classpath is called; a hook for removing duplicate dependencies from the project etc.

leiningen.droid.(code-gen|compile|build|deploy) mostly consist of subtasks and helper functions that bring the project the whole way from clean target to a deployed application.

leiningen.droid.manifest hosts functions that operate on AndroidManifest.xml and its templates, create and parse manifests.

leiningen.droid.new namespace is a home to new subtask that creates new Clojure-Android projects from a template. Template resources live in res/templates/ directory.

leiningen.droid.sideload is an utility namespace that allows to dynamically load some tooling libraries that can only be obtained from SDK directory, and exposes functionality of those libraries via reflection.

leiningen.droid.test provides a subtask for running local tests in Clojure-Android projects.

leiningen.droid.utils contains general-purpose utilities which are used by other namespaces.

Dev environment

You can develop lein-droid using the CIDER or any other REPL provider. If used with CIDER, you’d have to comment :eval-in-leiningen true line, and add [leiningen "2.5.1"] to the dependencies (this is a workaround for a bug in Leiningen). Now you can jack into the plugin.

There is a function leiningen.droid.utils/proj. By default it reads project.clj file of a sample project. You can modify it to read any project you want, so that you can call commands on your own project right from the REPL.

There is another secret for convenient development. If you call lein droid ... subtasks from lein-droid/ directory, it won’t use lein-droid JAR from the Maven repository, but the code from the disk. So if you go to leiningen.droid/droid function and replace this:

(some-> project
        android-parameters
        (execute-subtask cmd args))

with:

(some-> (proj)
        android-parameters
        (execute-subtask cmd args))

you’ll be able to execute lein-droid subtasks from lein-droid/ folder like you are doing that from your project folder, and using the latest changes you’ve made to the plugin. But to do that you’ll have to have :eval-in-leiningen true in lein-droid’s project.clj, so you must comment/uncomment that line every time you restart a REPL.