Geertjan's Blog

  • April 22, 2005

Efficient Deployment via Ant Scripts from NetBeans IDE 4.1

Geertjan Wielenga
Product Manager
Until now, I've been creating unnecessarily complex Ant scripts for deployment of applications to the server. What I've been doing is writing scripts that compile the classes and then move the whole application, piece by piece, to the server. (I don't compile the JSP pages, because the server does that automatically. In the case of Tomcat, JSP compilation happens the first time a JSP page is accessed. Click here for an earlier blog entry on this.) Then the server deploys it automatically, because I've moved the application to a very specific place on the server: its autodeploy directory. (For example, for JBoss this is \\server\\default\\deploy.)

However, now that I've read Brian Leonard's article Integrating NetBeans with other J2EE Server Vendors, I realize I've been doing a lot of unnecessary work, at least for standard IDE projects. This is the target he uses to deploy his application:

 <target name="jboss-deploy" depends="init" description="Deploy to JBoss">
<copy file="${dist.dir}/${jar.name}" todir="${jboss.deploy.dir}"/>

Could it be any simpler?! Since the IDE's build script can compile the classes for you, and since it also creates an archive file (EAR, WAR, or JAR) from your application, what's the point of redoing all of that? None. Except, of course, when you're using your own Ant script (i.e., in a free-form project), which means that the IDE doesn't compile classes nor create archive files unless you specifically provide Ant targets for this purpose. But even in that case, it makes more sense to compile and build everything in some local directory and, once everything is nicely wrapped up in an archive file (by the way, I miss the days when an EAR was the thing attached to my head, a WAR was a fight between countries, and a JAR contained nothing but milk), to move only that archive file to the server's autodeploy directory.

Once the archive file is in the server's autodeploy directory, all you've got to do is open a browser, type in the host, the server's port number, and the application's context (together with, optionally, a relative URL), and you're done. (In other words, you don't even need an Ant target for this. But then, you don't really need an Ant target to copy the archive file to the server's autodeploy directory either -- you could simply go into your filesystem, copy the archive file in your NetBeans project folder, and then paste it in your server's autodeploy folder. But then again, that's why we're using an IDE, to be able to do everything from one place with one click of one button or one menu item.) This is how Brian does it in his article:

  <target name="jboss-run-app" description="Launch application in browser">
<nbbrowse url="${jboss.client.url}"/>

There are two weird things about JBoss, however. The first is that even though it deploys an archive file, you can't access the deployed application at jar.name (the full name of the archive, i.e., together with the extension), but only at the application name. (And I think Brian's jboss.client.url specifically names the application because he wasn't aware that ant.project.name concatenates to the same thing. This property isn't visibly exposed in any file anywhere and I found out about it from some NetBeans developers a week or two ago.) When you use Tomcat, for example, you can access the application in your browser using the full name of the archive (i.e., including the extension). Secondly, when Tomcat deploys an archive, it automatically unpacks it so that you can see exactly what has been deployed. Unfortunately, JBoss doesn't do this.

So, getting back to the point, since the server needs nothing more than an archive file, my Ant file is going to be much shorter, neater, and more compact than it would otherwise be. And, with both standard and free-form projects, compiling and building applications is something that I will do locally, using the IDE where possible, and only move the archive file (EAR, WAR, or JAR) to the server's autodeploy directory.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.