2011-11-23 11 views
8

Me preguntaba si hay una manera de desarrollar plugins de Eclipse en Clojure. Para ser claros, la pregunta no es sobre usar Eclipse para escribir el código de Clojure.¿Cómo desarrollar los plugins de Eclipse en clojure?

Tanto Eclipse como Clojure se ejecutan en la JVM y creo que debería haber una forma de aprovechar la potencia de Clojure (y sus bibliotecas) para desarrollar complementos. Estaba buscando específicamente usar Korma, pero en general me gustaría mover complementos completos a Clojure si existe una forma natural de hacerlo.

+0

Después de pensarlo un poco, tuve una pequeña lluvia de ideas y busqué OSGI y Clojure y encontré esta publicación sobre [correr clojure bajo OSGI] (http://www.talios.com/clojure_running_succ essfully_under_osgi.htm) y un [hilo de correo electrónico] (http://osdir.com/ml/clojure/2009-10/msg00113.html) lo que implica que no es una buena idea. Un poco confuso. – Punit

Respuesta

10

En sentido antihorario, el plugin de Eclipse para Clojure está escrito en Java y Clojure. Utiliza clojure.osgi 1.2.10 todavía.

Por lo tanto, es una prueba de concepto en vivo que es posible. Y AFAIK, Counterclockwise se usa con éxito por cientos de personas.

Existen algunas limitaciones, sin embargo: el espacio de nombres de Clojure es "global" para algunos "cargadores de clases raíz". P.EJ. si empaqueta Clojure dentro de un paquete llamado, por ejemplo, myapp.clojure, entonces probablemente tendrá muchos otros paquetes que requerirán myapp.clojure. Digamos por ejemplo myapp.bundle1, myapp.bundle2. Cuando lo haga y, de cada paquete, cargue en memoria (requiera) los espacios de nombres de paquetes, cada uno se cargará desde el ClassLoader correcto (los espacios de nombres de myapp.bundle1 se cargarán dentro del cargador de clases de contexto de myapp.bundle1, y los espacios de nombres de myapp.bundle2 se cargarán dentro del cargador de clases de contexto de myapp.bundle2). Esto es genial, porque permite que la interoperabilidad Java funcione bien.

Pero recuerde que al final, los espacios de nombres cargados del paquete1 & bundle2 se mantendrán en el "mundo del espacio de nombres global" en el paquete myapp.clojure.

Para ser sincero, esto aún no ha demostrado ser un problema para el sentido antihorario. Porque dentro de la misma característica, tener los paquetes compartiendo una sola instancia de Clojure está casi bien.

Los posibles inconvenientes son:

  • si se utilizan bibliotecas de terceros, por ejemplo, tools.logging, no podrá tener espacios de nombres en myapp.bundle1 dependerá de la versión X de tools.logging, y al mismo tiempo tendrá myapp.bundle2 dependiendo de la versión Y de tools.logging. Es decir, dentro de su función, donde tiene un clojure compartido a través del paquete myapp.clojure, usted trabaja como si las reglas OSGi no se aplicaran, como webapps, por ejemplo.
  • no escala bien si se aplica de forma masiva: si cada característica de Eclipse fuera a volver a empaquetar su propia versión de Clojure, habría un desperdicio de memoria. Pero este inconveniente es más teórico que práctico, aún. Y este es un problema que se puede abordar más adelante, cuando surge la necesidad de hacerlo.

Tenga en cuenta que para un producto Eclipse RCP, a diferencia de un plugin de Eclipse, estos inconvenientes desaparecen.

Si desea ver cómo antihorario ha reenvasado clojure, y utiliza clojure.osgi, se puede ver en su código fuente:

http://github.com/laurentpetit/ccw.clojure.git http://github.com/laurentpetit/ccw.git

HTH,

- Laurent

3

Es perfectamente posible escribir plug-ins de Eclipse en Groovy o Scala. Como Clojure produce archivos .class, no debería ser diferente. Sin embargo, los complementos normalmente se exportan utilizando PDE Build, que solo maneja Java de forma predeterminada, por lo que tendrá que escribir un archivo customCallback.xml que puede compilar Clojure (consulte http://www.michel-kraemer.com/scala-projects-with-eclipse-pde-build-2 para Scala build).

Cuestiones relacionadas