Im sure my answer / comment on What is Gradle in Android Studio? will get downvoted into oblivion with short-shrift fairly soon. (Maybe deservedly).

But I’ll make it here :


At the risk of being discursive I think behind this is the question of why the Android Studio / Gradle experience is so bad.

Typical Clojure experience :

* download project with dependencies listed in project.clj.
* Leiningen gets the dependencies thanks to Clojars and Maven.
* Project compiles.

Typical Android Studio / Gradle experience :

* “Import my Eclipse project”.
* OK project imported.
* Gradle is doing it’s thang … wait … wait … wait … Gradle has finished.
* Compile … can’t compile because I don’t know what an X is / can’t find Y library.

I’m not sure this is Gradle’s fault exactly. But the “import from Eclipse project” seems pretty flaky. For all of Gradle’s alleged sophistication and the virtues of a build-system, Android Studio just doesn’t seem to import the build dependencies or build-process from Eclipse very well.

It doesn’t tell you when it’s failed to import a complete dependency graph. The Android Studio gives no useful help or tips as to how to solve the problem. It doesn’t tell you where you can manually look in the Eclipse folders. It doesn’t tell you which library seems to be missing. Or help you search Maven etc. for them.

In 2016 things like Leiningen / Clojars, or node’s npm, or Python’s pip, or the Debian apkg (and I’m sure many similar package managers for other languages and systems) all work beautifully … missing dependencies are thing of the past.

Except with Android. Android Studio is now the only place where I still seem to experience missing-dependency hell.

I’m inclined to say this is Google’s fault. They broke the Android ecosystem (and thousands of existing Android projects / online tutorials) when they cavalierly decided to shift from Eclipse to Android Studio / Gradle without producing a robust conversion process. People whose projects work in Eclipse aren’t adapting them to AS (presumably because it’s a pain for them). And people trying to use those projects in AS are hitting the same issues.

And anyway, if Gradle is this super-powerful build system, why am I still managing a whole lot of other dependencies in the sdk manager? Why can’t a project that needs, say, the ndk specify this in its Gradle file so that it gets automatically installed and built-against when needed? Why is NDK special? Similarly for target platforms? Why am I installing them explicitly in the IDE rather than just checking my project against them and having this all sorted for me behind the scenes?


I’m updating my copy of the Smallest Federated Wiki, and the plugin format has evolved again. (Not surprising, the SFW is still in its experimental stage.)

So, I’ve broken out my plugin for ThoughtStorms / SdiDesk format (wikish) from the original Project ThoughtStorms and made a dedicated git repository in the recommended format, naming convention etc.

The plugin is also now available as a node npm package on npmjs for easy installation.

Last year I wrote about how impressed I was by Clojars, the Clojure package repository. Seems like this might actually be the standard way things are done these days. Because npm seems equally straightforward.

The latest instructions for installing extra plugins to your copy of the SFW seem to be here.

Further to this story.

I tried to deploy another small Clojure library to Clojars today. And found myself being asked for the passphrase to sign my update.

You need a passphrase to unlock the secret key for
user: “phil jones
2048-bit RSA key, ID XXXXXX, created 2012-03-05

I got into a terrible confusion. Because, for the life of me, I couldn’t remember what passphrase I’d chosen to sign my Clojar last time. Had I just locked myself out of my Clojars account and the existing group and Patterning project?

A couple of hours faffing and I figured it out :

– my previous library WASN’T signed. It’s just in “Clojars Classic” and isn’t “promoted” so doesn’t require signing. That’s why I don’t remember signing it or inventing a pass-phrase.

– the reason that lein deploy was demanding a pass-phrase THIS TIME, was that in this library I’d decided to remove the word SNAPSHOT from the id in defproject.

lein deploy assumes that SNAPSHOTs default to being deployed in classic (the “free-for-all” part of Clojars) whereas non-SNAPSHOTS are intended to be deployed in the new “releases” repository, which is slightly more formalized arrangement, requiring author signing.

– I have gpg on my machine, and I did set up signing for my email address a couple of years ago. This was nothing to do with the previous library I put on Clojars. It was when I was experimenting with encrypted email. (A practice that I’ve embarrassingly let slip since then, but should really go back to.) So that’s the pass-phrase that was being demanded, and that I’ve managed to forget (from 2012, not end of 2014). Not impressive, but not quite as bad as creating one four months ago and then totally forgetting about it.

That still leaves me with some problems when I eventually will want to put my libraries into “releases”) but at least I can still use Clojars. The library will have to continue as a SNAPSHOT though.

Well that was surprisingly painless.

I’m in the process of reorganizing the code for Patterning, my Clojure library that produces (visual) patterns.

Patterning was built using Quil, which is a Clojure wrapper around Processing. But I wanted to be able to call the library directly from Processing itself (Java version).

It seemed silly to create an uberjar file containing the whole of Quil and Processing, to be called from … er … Processing, so I decided to split the project into the core (pure Clojure, no Quil or Processing dependencies) and a Quil based wrapper.

I’m also, compiling the library using ClojureScript to run in the browser. (Called from Javascript). Once again this part doesn’t want any Quil / Processing dependencies.

But I was a bit stumped with how to manage some of this. My previous experience of projects that rely on other projects (git submodules) has been somewhat painful.

But it seems the Clojure (via Java) world has actually sorted this. All I needed to do was create an account over on Clojars and type :

lein deploy clojars

to put the JAR for my Patterning library there.

And so here it is.

Including it in a new project is as simple as referencing it in the project.clj file. There’s a simple test project which combines both Patterning and Quil. And here’s the very simple project.clj file. Note the patterning dependency.

(defproject com.alchemyislands/patterning_quil "0.1.0-SNAPSHOT"
:description "Quil Wrapper for Patterning library"
:url ""
:license {:name "Eclipse Public License"
:url ""}
:dependencies [[org.clojure/clojure "1.5.1"]
[org.clojure/math.numeric-tower "0.0.4"]
[quil "1.7.0"]
[com.alchemyislands/patterning "0.3.0-SNAPSHOT"]]
:aot [patterning_quil.core]
:main patterning_quil.core

And that’s more or less it.

If you want to use Patterning in your own projects, just include it like that. If you still want to be using Quil, then use this as your example.

BTW: the new development for the core Patterning library is now at

I’m not sure I understand Brent Simmons’ problem, here.

If you need the same code running on two or three small specialized web-servers, just write it once in a library and include it in each of them. The repetition of running instances isn’t worth worrying about.

I’m wondering if his problem is really a lack of an obvious “include” for common html components in a world of single-page node.js apps? In which case, is this really a package management question?