core.clj

(ns classpath-test.core
  (:require [clojure.java.shell :refer [sh]]
            [cemerick.pomegranate :as pom]))

(defn make-java
  [class-name
   package]
  (str "package " package ";"
       "public class " class-name " {"
       "public static String foo() { return \"bar\"; }"
       "}"))

(defn import-by-name [n]
  (.importClass (the-ns *ns*)
                (clojure.lang.RT/classForName n)))

(defn compile-load-run
  []
  (let [class-name "Service"
        package (str "foo" (System/currentTimeMillis)) ;; use a random package
        location (str "/tmp/" package)
        _ (.mkdir (java.io.File. location))
        java-filepath (str location "/" class-name ".java")]
    (println "spitting " java-filepath)
    (spit java-filepath (make-java class-name package))
    (println "compiling")
    (sh "javac" "-sourcepath" "/tmp" java-filepath)
    (println "importing")
    (pom/add-classpath "/tmp")
    (import-by-name (str package "." class-name))
    (println "running")
    (eval '(Service/foo))))

Just for effect, spit a java file and compile it on the spot. We'd be using wsimport obviously, rather than javac (which also comes w/ the jdk and should be fair game).

This is largely useless though. There are really only two cases to consider:

1. Service contract doesn't change, but service versioned. In that case, we should do nothing (use latest version we can find). Dynamically generating/loading service client classes gains us nothing in this case.
2. Service contract changes + versioned. In this case, we must make code changes to randr. And so we must restart randr. Unfortunately, this means dynamically generating/loading service client classes does not accomplish the goal of preventing randr restarts/rebuilds in this case.

IMO, there is no point to dynamically generating service client jars other than the mild convenience of having them around to use. It would in no way help prevent randr deployment.

Furthermore, even if we had the equivalent of Ruby Savon w/ complete runtime flexibility, we would still have to redeploy randr when the service interface changed. Savon doesn't protect you from your service's interface changing out from under you.