tags:

views:

192

answers:

3

I have a J2EE application that needs to be distributed to customers, who will have application servers of their own choice. What is the recommended way of writing a build script that would compile the J2EE application sources (at customer sites) so that they will eventually be able to deploy the application on their servers ?

Moreover, what JARs should one actually use during the compilation process ? Since this is meant to an application server agnostic script, is it recommended to use the JARs (say servlet.jar, jms.jar, ejb.jar etc.) from the application server, rather than having my customers download these JARs from a particular repository ? Is there any such repository that is recommended for such JARs (JARs of J2EE APIs) ?

PS: The EAR file cannot be built locally and shipped to customers, since additional development will be done at each installation to integrate with other systems, perform customizations on the application etc.

A: 

Basically, don't include the container jars (servlet.jar, jms.jar, ejb.jar etc.) in your EAR or WAR file.

If you are just talking about servlet.jar, the web container provides that - you shouldn't include it in your war file.

If you are creating an EAR file, they you must be using an enterprise container and it will have a JMS.jar and EJB.jar.

JMS on Tomcat would be a little trickier - you'd need people to install something like activemq on their servers.

stevedbrown
Agreed about the container providing the jars. But the point is, the build script would need these jars during compilation. I personally dont think I should be trying to refer to these jars unless I have a build script per server, and unless I know where these jars lie on every server.
Vineet Reynolds
By the way, the application is deployed on J2EE containers, so Tomcat is not something that our customers deploy the app on.
Vineet Reynolds
These jars come with Java EE.
stevedbrown
+1  A: 

Build the application locally, and distribute the WAR/EAR files to the customer.


Edit:

The situation you describe is basically that you need to provide a code base for further development by the customer. In that case I would suggest that you look into creating maven modules of your work which are pushed to a private repository accessible by the customer. You then let them know that they need to depend on module X version Y in their pom.xml, and module X then pulls in all the libraries needed in the correct versions.

Note that if they don't use Maven, they might use Ant Ivy for the dependency resolving.

Thorbjørn Ravn Andersen
Thanks, that was thought of when preparing the deployment strategy, but was ruled out. I've updated the question to indicate why.
Vineet Reynolds
Well, we haven't looked into a internet based repository, since we don't intend to distribute the JARs, but that is something we're not ruling out anyway. I would, however like to know what JARs should anybody use for distribution anyway - for instance, where should I ideally get the servlet.jar from? I do not think it is wise to host a repository with a servlet.jar (among others) obtained from a vendor.
Vineet Reynolds
It shouldn't matter, as the classes in it belongs to a namespace/package not loaded by the web container classloader. I did the patch for slf4j where we just picked the Geronimo one.
Thorbjørn Ravn Andersen
Yes, I agree. Since it wont be packaged in the EAR, there will be no runtime issues. However, I'd rather redistribute the JARs taken from the source, rather than any other, purely from a legal perspective (easier for tracking copyrights and licenses).
Vineet Reynolds
Note, you will need servlet. jar for _compilation_, not _deployment_. E.g. Tomcat actually warns that the classes will not be loaded.
Thorbjørn Ravn Andersen
I think I got my answer. I could use the API jars provided for download in the JSRs, for compiling the sources; during runtime, the application will obviously depend on the container provided implementation.
Vineet Reynolds
+1  A: 

Some generic J2EE API jars can be found at Sun's site, however you might have to dig a lot to find them.

I would just use any JAR you have handy, bundle it with the source, but away from /WEB-INF/lib

alex
Yes, the problem is the digging involved. Would have preferred that Java API jars have a repository similar to the Maven repositories, because it would have been pretty easy to point out people to URLs and place the jars in the lib directory before a build.
Vineet Reynolds
And if it isnt already bad enough, Sun wants me download a full blown application server to obtain a copy of j2ee.jar and servlet.jar (aka the SDK).
Vineet Reynolds
Thats for pointing me out in the right direction. I figure out I could get the jars I needed for compiling the sources, from each individual JSR.
Vineet Reynolds