3 ms·
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 d
by cemerick 17y ago
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 17y agoI'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 17y agoIn 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.