
Sane web development with Compojure, Jetty, and Maven - icey
http://muckandbrass.com/web/display/~cemerick/Sane+web+development+with+Compojure%2C+Jetty%2C+and+Maven
======
gcv
This is a little silly. I haven't played with Compojure, but Maven, and all
this save-file-to-reload stuff is completely unnecessary with the Clojure and
Jetty combination.

Clojure is a Lisp, and like any decent Lisp, gives you full access to the
compiler at runtime. This means that, if you wire your app to Jetty correctly
— remember that Jetty can run embedded in your app, rather than making your
app run inside its container — you can just recompile whichever functions you
modified and see the application change on the fly. No XML, no scanner
intervals, and no additional complexity. I don't know about Enclojure
(Eclipse) or La Clojure (IntelliJ IDEA), but with Emacs and SLIME, it's just a
matter of hitting C-c C-c to recompile the current function.

~~~
cemerick
I'd agree with you if I were just building a weekend project in my free time
using only clojure and jetty.

However, we're building things with an eye towards deploying in a standard
Java container (e.g. war packaging), so there's more moving pieces than just
clojure and jetty.

FWIW, I can do what you describe using enclojure (which is a _netbeans_
plugin, not eclipse BTW) when I want to as well.

~~~
gcv
I've dealt with deploying Java apps in-container, as .war files, and it has
invariably been painful. Deployment to a new server requires installing the
container first. Then configuring it, an excruciating process of editing many
XML files. Configuration management for production, staging, QA, and
development environments almost immediately becomes a whole separate set of
fragile programs and scripts.

I have found it much easier to treat the main app as just a piece of software
that happens to interact with the rest of the world using HTTP. Deployment
becomes trivial; it really just needs a startup script and a directory of .jar
files (dependency libraries) and another .jar or directory of .class files for
your actual application. Installing on a new server doesn't require much more
than a pre-installed JVM.

Out of curiosity, what value does deploying in a container add for you?

~~~
cemerick
In no way am I trying to be enterprisey (although if we do end up selling this
software to some customers, it'll be very nice to be able to say "here's a
standard .war").

My aim is to make it as simple and easy as possible to enable continuous
deployment across multiple nodes. In that context, the (re)deployment
facilities provided by any container beats coordinating things on the command
line.

------
koevet
I have been playing around recently with Play! Framework
(<http://www.playframework.org/>). It has functional programming support
(Scala), write-save-compile-deploy takes 0 seconds, it's java, can be deployed
as War in every container, has several goodies already built in.

~~~
warfangle
How does this compare to the Lift framework?

Seems to me that if you'd rather write in a functional style (scala), having a
framework that is written in a functional style that has the benefit of actor-
based concurrency and Comet (Lift) might be a better choice. It can also be
deployed as a WAR...

What are the benefits to using Play! over something like Lift, especially if
you'll be building in Scala?

~~~
koevet
I never looked into Lift, so I can't answer your question directly. Play!, I
believe, has to offer a smoother learning curve. You can mix Scala and Java
code (eg. controllers in Java, service layer code in Scala) and migrate fully
to Scala when confident enough. Frankly, as much as I like Actor concurrency,
I don't think you'll use it a lot if a web application.

