Current status of experiments with Eclipse 4 for Clojure development of Counterclockwise.

gistfile1.clj

(require '[ccw.util.e4 :as e4])

;; plumbing/kernel functions: no reflection, follows closely eclipse Application Model/Semantics, 
;;                            no magic (no nice-to-have coercition, only the ones that make total sense)
;;                            , simple
;; porcelain/user functions: relax reflection constraint as appropriate, pay as you go (thus can depart from eclipse 
;;                           semantics/Application Model), more fancy coercitions, etc.
;;                            , easy

(def cmd-id "hello-6")
(def app (context-key @e :application))

;; DEMONSTRATION of plumbing/kernel functions (as opposed to soon to come porcelain/user functions)

(-> app
  ; add the command to the Application model
  (e4/add-command! ; create a Command model object 
                   (e4/make-command 
                     app
                     {:element-id   cmd-id
                      :command-name "Run Generic Leiningen task"
                      :category     "org.eclipse.ui.category.window"}))
  ; add the handler to the Application model
  (e4/add-handler! ; create a Handler model object
                   ; e4/make-handler takes care of resolving cmd-id into the application command
                   ; object (the command must have been added to the application model first)
                   ; contribution-URI protocol has been extended to clojure via the org.eclipse.languages extension point
                   (e4/make-handler 
                     app
                     {:command cmd-id
                      :contribution-URI "bundleclass://ccw.core/clojure/ccw.leiningen.generic-launcher/prompt"}))
  (e4/execute-command cmd-id))

;; DEMONSTRATION of porcelain/user functions
(e4/merge!
  editor ;; Anything that has been extented to protocol HasContext can do
  {:commands [{:cmd-id cmd-id ; :cmd-id still important for idempotence (or we recreate / delete old everytime ?)
               :name "Run Generic Leiningen task"
               :category "org.eclipse.ui.category.window"}
              {:cmd-id cmd-id2 ; :cmd-id still important for idempotence (or we recreate / delete old everytime ?)
               :name "Kill started Leiningen tasks"
               :category "org.eclipse.ui.category.window"
               :var "ccw.leiningen.generic-launcher/kill-all"}
              ]
   :handlers [{:cmd-id cmd-id
               :var    'ccw.leiningen.generic-launcher/prompt ; we accept directly a var symbol, a var, a string denoting a var or a bundleclass://
               }]}
  ;; the merge! function is variadic, we can pass additional model elements
  ;; the order should not be important, we will apply model modifications in the right order (commands first, then handlers, etc.)
  ;; thus the application model parts to merge can be passed piece by piece with references to the parent (TBD), we will first re-normalize
  ;; the model, then pass it to the (TBD) plumbing merge! function
  {:cmd-id cmd-id ; :cmd-id allows to identify a command. Thus we may have :part-id, :menu-id.
                  ; Or a separate :type :cmd => maybe :cmd-id / :menu-id is better for cross-referencing mnemotechnics 
   :name "Run Generic Leiningen task"
   :category "org.eclipse.ui.category.window"}
  {:cmd-id cmd-id
   :var #'ccw.leiningen.generic-launcher/prompt})