7

Are there any well-integrated application-management stacks that allow the build, deployment and updating of non-.war Java applications that run as servers? For example message consumers that are servers (but not webservers and have no Servlets), or executable .jars with Jetty embedded?

Building and deploying .wars is pretty straightforward: Maven has the war archetype, Jenkins has a heap of plugins for deploying .war files to various application servers, most of which accept the upload of new web applications at runtime. Tools like Elastic Beanstalk make this process even easier, tying in the management of server environments.

By contrast deploying executable .jars seems like re-inventing the wheel. One needs to sort out the best way of shading the dependencies and creating an executable artefact with a plethora of Maven plugins, deposit this artefact somewhere, then find a way of installing it on target servers, and replacing/upgrading it if necessary (Debian packages would be one way of doing this).

This all seems very 'manual' to me, to the point that it seems advantageous to deploy applications as .wars to application servers, even if they're not a natural fit for such an environment, just so you get the benefit of tool support.

DeejUK
  • 12,891
  • 19
  • 89
  • 169
  • for message consumers, would MessageDriven EJBs be a good fit? Those could be published to an app server as a JAR. – wrschneider Jul 20 '12 at 01:53
  • They could well be - unfortunately I'm at a small startup who consider anything "heavyweight" to be the work of Satan. – DeejUK Jul 20 '12 at 07:40

2 Answers2

4

You could implement this by deploying your applications to an osgi container.

You could hook into the osgi lifecycle to run your application when the osgi bundle starts. Then you can remotely start and stop the container (if the container supports that).

Your applications could define their dependencies as part of the osgi manifest - but shading jars using the shade plugin is not difficult when using maven and I think it would be easier to manage rather than deal with hundreds of jars in your container.

This question talks about continuous deployment of osgi bundles using jenkins.

An alternative (and more standard) way would be to write scripts that automate the deployment - possibly using purpose built tools like puppet or chef. There is a maven plugin for puppet that allows you to extract artifacts from a maven repo for use in your puppet scripts.

Running puppet or Chef from jenkins is trivial and if you want, you can provide access to the deployment builds to non-technical staff members, to allow them to deploy new builds to an environment with a click of a button.

Like @bagheera suggests building rpms of your applications and starting them as services is a good way to go and reduces the complexity of your deployment scripts.

Community
  • 1
  • 1
plasma147
  • 2,191
  • 21
  • 35
  • Thanks for the answer - I'll look into OSGi. With regards to writing scripts, this was generally the approach I was hoping to avoid, but it looks like that might not be possible. – DeejUK Jul 16 '12 at 10:43
  • If you pair script writing with the rpm suggestion then the scripts are very simple 1.) download rpm from the maven repo 2.) install the rpm. This [slideshow](http://www.slideshare.net/actionjackx/automated-java-deployments-with-rpm) shows how simple the scripts become after going with rpms - it uses webapps as it's example but jars are just as valid. – plasma147 Jul 16 '12 at 11:36
3

It seems like you are looking for a dependency manager for building your self-contained executable jar, and a package manager for deployment. Other than the tools you have mentioned, you could check out ant+ivy for build+dependency mgmt and rpmbuild+rpm+yum for package management on linux.

ottodidakt
  • 3,631
  • 4
  • 28
  • 34