In this post I started investigating interoperability between Clojure and Java in the setting of my IDE of choice (IntelliJ). We all agree that the compile.clj strategy is somewhat sub-optimal.
It is easy to set-up and works with every IDE, that is positive. However, we have to keep track of the clojure scripts manually. This is true only partially: it is not overly hard to come up with some automated stuff. For example, considering this library and the walk function, it would be very easy.
However, this is the direction of rolling up your own build-system for clojure. This is highly sub-optimal, in my opinion. As far as I know there are at least two with some community acceptance (cake and leiningen). Seems clojure community likes github < bitbucket.
So, leaving out the leiningen solution, I have to work it out with my IDE. IntelliJ has a nice feature which essentially generates the ant files necessary to build the project.
I wrote (well, copied/adapted from Bob Martin post) this additional buildfile.
Martin put the compile target inside another project, I created a project just to build clojure targets.
Then I have just to include this in the main module and somewhat place it among the dependencies (with special regards to having clojure compiled before/after Java, depending on your necessities).
Up to now we essentially have an ant based (IDE independent) build script for our project, which neither depends on cake or leiningen, neither is the beginning of the nth clojure build-system.
Moreover, it can be integrated with the IDE. The idea is just to add the ant action building clojure to the rest of the IDE build-system.
The funniest thing is that today (after some days from the original experimentations) I discovered that IntelliJ clojure plugin has a feature that should solve my problems.
I guess that with little fiddling with the options I should automagically get the desired behaviour.
It is easy to set-up and works with every IDE, that is positive. However, we have to keep track of the clojure scripts manually. This is true only partially: it is not overly hard to come up with some automated stuff. For example, considering this library and the walk function, it would be very easy.
However, this is the direction of rolling up your own build-system for clojure. This is highly sub-optimal, in my opinion. As far as I know there are at least two with some community acceptance (cake and leiningen). Seems clojure community likes github < bitbucket.
So, leaving out the leiningen solution, I have to work it out with my IDE. IntelliJ has a nice feature which essentially generates the ant files necessary to build the project.
I wrote (well, copied/adapted from Bob Martin post) this additional buildfile.
Martin put the compile target inside another project, I created a project just to build clojure targets.
Then I have just to include this in the main module and somewhat place it among the dependencies (with special regards to having clojure compiled before/after Java, depending on your necessities).
Up to now we essentially have an ant based (IDE independent) build script for our project, which neither depends on cake or leiningen, neither is the beginning of the nth clojure build-system.
Moreover, it can be integrated with the IDE. The idea is just to add the ant action building clojure to the rest of the IDE build-system.
The funniest thing is that today (after some days from the original experimentations) I discovered that IntelliJ clojure plugin has a feature that should solve my problems.
I guess that with little fiddling with the options I should automagically get the desired behaviour.
2 comments:
There is a plugin for Intellij for leiningen that works in the same way as the Maven plugin. The only issue I encountered that it does not put the files in the lib directory automatically in the classpath, but that can be done easily by hand
I know the plugin, I have installed it. Though, I did not use it.
In fact, I plan to grok leiningen for a clojure only project. I'm sure it will give its best.
For this project I'm not sure how much clojure there will be. Consequently, it is far easier to let clojure specific tools out for now. At the moment, for example, I converted all clojure code to Java.
For the kind of code I had to write *now*, it was just clojure calling some Java API in a :gen-class scenario.
I think I will have more clojure in the future. The idea came because there is a certain set of the project APIs (which I haven't used yet). They are rather verbose because of Java, essentially using anonymous classes where in a functional language closures would have been used.
I want to write a bunch of macros to make the thing more manageable.
Post a Comment