I was wondering if there is a way to develop Eclipse plugins in Clojure. To be clear, the question is not about using Eclipse to write Clojure code.
Both Eclipse and Clojure run on the JVM and I feel there should be way to leverage the power of Clojure (and it's libraries) to develop plugins. I was specifically looking at using Korma, but overall I would like to move complete plug-ins to clojure if there is a natural way to do it.
Counterclockwise, the Eclipse plugin for Clojure, is written in mixed Java and Clojure. It uses clojure.osgi 1.2.10 yet.
So it is a live proof of concept that it is possible. And AFAIK, Counterclockwise is used successfully by hundreds of people.
There are some constraints, tho: Clojure's namespace is "global" to some "root classloader". E.G. if you package Clojure inside a bundle named, say, myapp.clojure, then you'll probably have a bunch of other bundles which will require myapp.clojure. Say for example myapp.bundle1, myapp.bundle2. When you do so, and, from each bundle, load in memory (require) the bundles namespaces, each one will be loaded from within the right ClassLoader (namespaces of myapp.bundle1 will be loaded within the context classloader of myapp.bundle1, and namespaces of myapp.bundle2 will be loaded within the context classloader of myapp.bundle2). This is great, because it allows java interop to work okay.
But just remember that in the end, namespaces loaded from bundle1 & bundle2 will be held by the "global namespace world" in bundle myapp.clojure.
To be honest, this has not yet proven a problem for Counterclockwise. Because inside the same Feature, having the bundles share one single Clojure instance is almost okay.
The potential drawbacks are:
if you use third party libraries, e.g. tools.logging, you will not be able to have namespaces in myapp.bundle1 depend on version X of tools.logging, and at the same time have myapp.bundle2 depend on version Y of tools.logging. That is, inside your feature where you have a shared clojure via bundle myapp.clojure, you work as if OSGi rules did not apply, as webapps work, for example.
does not scale well if massively applied: if every Eclipse Feature were to repackage its own version of Clojure, there would be some waste of memory. But this drawback is more theoretical than practical, yet. And this is a problem that can be addressed later, when the need for it emerges.
Note that for an Eclipse RCP Product, as opposed to an Eclipse plugin, these drawbacks vanish.
If you want to see how Counterclockwise has repackaged clojure, and uses clojure.osgi, you can look at its sourcecode:
http://github.com/laurentpetit/ccw.clojure.git
http://github.com/laurentpetit/ccw.git
HTH,
-- Laurent
It seems it's not available in Eclipse 3.x, but is planned for Eclipse 4, as mentioned in http://wiki.eclipse.org/E4/Languages .
There's also a post here on Stack Overflow asking about development of Eclipse plugins in languages other than Java that may have more information that you'd find useful.
It's perfectly possible to write Eclipse plug-ins in Groovy or Scala. Since Clojure produces .class files, it should be no different. However, plugins are normally exported using PDE Build, which only handles Java by default, so you will have to write a customCallback.xml file which can compile Clojure (see http://www.michel-kraemer.com/scala-projects-with-eclipse-pde-build-2 for Scala build).
Related
Considering that I am developing an end-user software program (as an uberjar) I am wondering what my options are to make it possible for the user to download a plugin and load that during runtime.
The plugin(s) should come compiled and without source code, so sth. like load is not an option.
What existing libraries (or ways of Java...?) exist to build this on?
EDIT: If you are not sure I would also be satisfied with a way that costs a reboot/-start of the main-program. However, what is important is that the source-code won't be included in any JAR file (neither main application nor plugin-jars, see :omit-source of Leiningen documentation).
To add a jar during runtime, use pomegranate which lets you add a .jar file to the classpath. Plugins of your software should be regular Clojure libs that follow certain conventions that you need to establish:
Make them provide (e. g. in an edn) a symbol to an object implementing a constructor/destructor mechanism such as the Lifecycle protocol in Stuart Sierras component library. In runtime, require and resolve that symbol, start the resulting object and hand it over to rest your programs plugin coordination facilities.
Provide a public API in your program that allows the plugins to interact with it in ways that you coordinate asynchronously e. g. with clojure.core.async (don't let one plugin block the entire program).
Make sure that the plugins have a coordinated way to expose their functionality to each other only if they desire so to enable a high degree of modularity among your plugins. Make sure that your plugin loader is capable of detecting dependencies among plugins and is capable of loading and unloading them in the right order.
I've not tried it myself, but you should in theory be able to get OSGi to work with Clojure.
There's a Clojure / OSGi integration library here:
https://github.com/aav/clojure.osgi
If I were to attempt to role my own solution, I would try using tools.namespace to load and unload plugins. I'm not entirely sure it will work, but it's certainly in the right direction. I think one key piece is that the plugin jars will have to be "installed" in a location that's already on the classpath.
Again, this is only the start of one possible solution. I haven't tried doing this.
I think (see below) that I would like to structure a Clojure project as multiple modules, with ordered dependencies - just like Maven lets me do with multi-modules projects.
But I can't see how to do this with Leiningen - all I can see is the checkouts fix described in the FAQ which doesn't seem to be as powerful.
Will lein do this? Should I be using Gradle instead? Or is this kind of thing not needed?
Some more context: I am wondering how to architect a modular application that supports plugins (which I imagine means jars dumped on the classpath). And am wondering to what extent I can structure that as a core + plugins (I am thinking I should be able to do something with Clojure's dynamic code loading and not have to go with Java/OSGi). So I guess the driving motivation for a single project comes from wanting some way of packaging everything (the core + default plugins) as a single blob that is easy for the end user, but which can also be divided up (and which is built and tested in fragments, testing the logical independence of each module). More general advice about this is welcome
Update
A possible solution that wasn't mentioned below is using a Maven plugin - I assume that supports everything Maven does, but compiles Clojure, so will work with nested modules, etc.
First, it does not seem like Leiningen supports a module hierarchy like Maven does. The checkouts are the next closest thing it has. It should be sufficient though to develop a modular application in Clojure though.
For the project structure, I would have an API project, a "core" project, the plugins themselves, and a separate packaging project. The core and the plugins should only depend on the API. Which build tool you use to create the packaging project is up to you. Gradle would probably be more effective at handling the packaging, however having the "checkout" functionality Leiningen offers could make development of the system as a whole easier.
I would take a look at the code for Leiningen and Noir to figure out how to effectively handle this.
For dynamically loading the plugins, I would start with looking how Noir handles it in two of their files:
server.clj has namespace loading for all files under a particular namespace. Under the hood it uses tools.namespace, but you can easily see how it's used to require every namespace under a particular base. This is how Leiningen handles custom tasks as well - the base definition for the task should be in the leiningen.$task namespace.
core.clj has what I would use for plugin registration. In summary, use a map under an atom and add plugins to that map. I would advice wrapping the registration with a macro to keep your code cleaner.
What I listed above should be sufficient if you don't need to handle adding plugins at run time. If you don't have every plugin on the classpath during start-up, I would recommend utilizing pomegranite to add entries to the classpath. You can see an example in classpath.clj.
just changed from Netbeans to Eclipse just for fun (Only developer on the company, So I can code on whatever and with whatever I feel like.) That's why I liked the new version of netBeans over vim, it could load resources or plugins, I am not quite aware of their naming conventions, on demand. For example if you were working on a Grails project it would only load grails related resources.
On Eclipse I have a gazillion plugins installed. Some to emulate Netbeans functionality (Grails, JavaFX, Ruby, PHP, CSS, Python, etc.) And some others Netbeans lacks (Android, Vaadin, SpringRoo, Git and some others) But I am not sure how Eclipse handles this plug in behemothing
Does it load them on demand? Do I have to manually disable the ones I am not using? Do I have to have different installs for each language I work on? Or do I have to learn how to live with this big mess of plugins in order to have everything I need at hand??
Thank you very much for your time.
Basically Eclipse loads the plug-in codes lazily. On the other hand, the menu/toolbar contributions are loaded at the start of the platform.
If the plug-ins are written correctly, they should not interfere with each other, and the unnecessary elements should be few in the context menus.
My suggestion is to try this installation, and look for potential problems. If you have problems with the environment, only then try to identify and remove the plug-ins. But it should be ok.
What I mean by the title is, whether there's a free framework/tool that allows me to write .scala files and have them reloaded & compiled automatically by the (web) server without the need to compile, package and deploy.
Probably javarebel can be used here, but it is not free.
JRebel, which is the new name for JavaRebel, has a free license for Scala use.
Other alternatives include using Maven's scala:cc target, which keeps compiling on the background, triggered by changes, and, in particular, the Play framework is almost perfect in this regard.
Scala has an interpreter (scala.tools.nsc.Interpreter.) that can be embedded. The infrastructure to load changed files should not be to hard to implement. The interesting question is how do you handle instances of older class versions? The easiest approach is to throw away the instances and the classloader.
I do vaguely remember that JRebel is free for scala development. Not sure if this was only for open-source scala projects.
Is it possible to create Eclipse plugins/program Eclipse RCP apps without Java? (preferably in Jython)
This will be possible in the next Eclipse major release e4:
One of the goals of e4 is to provide support for writing plugins in other languages.
The quote is from http://wiki.eclipse.org/E4/JavaScript which summarizes the current state of using javascript to implement eclipse plug-ins in e4.
This issue in eclipse's bugzilla issue #227058 also has some discussion on that, but I believe it is outdated.
I am currently not aware of activity regarding other languages.
No. An Eclipse plugin is an OSGi bundle, and that requires interacting with a variety of things that can't implemented in Jython as far as I can see.
If you want to avoid Java, you can look at other things that target the JVM, but you will have to figure if you can produce and consume the specific items needed to call the necessary things and be called in the necessary ways.
OSGi bundles may be written in other JVM languages like Scala. Eclipse plug-ins, as of now, does not support any language other than Java. The Eclipse Plug-in Development Environment heavily makes use of JDT which ties it to Java. However there are some plans I heard that plug-ins might be supported in other languages. But I don't see that coming in near future.
You can write your main code in Jython and use Java interfaces to call then from Java. Take a look at this for details. Also, I am writing a utility library (github.com/abhin4v/jywrapper) to do the same. It has very little documentation right now, but you can look at the examples provided.