Rewrite clojure-maven-plugin in Java, duplicating some functionality of maven-exec-plugin

Configuration option to run in-process or fork

Rewrite clojure-maven-plugin in Clojure

Can it still launch a process with a different version of Clojure?

Radical Change Thought

Instead of having just "one" plugin, maybe it would be better to break it up to multiple artifacts/plugins, with specific functionality. For ultimate flexibility I'm guessing each of these artifacts would have to be a separate git repo, with their own lifecycles.

org.clojure.mojo/nsdiscovery

Namespace discovery code, the existing code, split out.

org.clojure.mojo/clojure-maven-embedder

Support code to actually execute clojure code, be it in process, forked.

Make use of clojure-jsr223 from Armando Blancas ( has signed contributor agreement ), project hasn't been updated since 2009, could be good to also move this under the org.clojure umbrella and give it some new life. By using a javax.scripting/forking model we keep the direct dependency on clojure outside of the plugin, allowing independent choice of version the end developers project. This would work well with my idea of having the mojo just a thin umbrella which delegates out to the actual implementation in clojure.

Use of jsr223 could probably even be used by the forked VM model as well.

Non-forked VMs would preclude any toolchain support/mixed VM

jsr223 support would also play well into embedded clojure scripts inside a POM somehow.

org.clojure.mojo/clojure-maven-plugin

The core of the original plugin

A single configurable source directory, with NO namespace configuration settings. We still use the nsdicovery artifact however, the original reason for namespace selection/filtering was when pulling in multiple clojure projects as git submodules etc. In a more modular world that we've moved to, with clojars and dependency management, I think this is no longer really needed. Maybe we need a compiler-directive metadata element that the compiler looks at to ignore/use, which all tools can then use?

Stripped down to maybe just the compile goal, and nothing else, default to a temporary output path so we get the strictness of compilation, but no AOT artifacts by default.

If we keep each goal, the mojo code should just delegate to an implementation in a supporting artifact - which may or may not be java or clojure based.