Batch Java Help

My company is trying to determine the best strategy for implementing batch Java programs. We have a few hundred (and growing) separate Java programs. Most of them are individual Jasper Reports but some are bigger batch Java jobs. Currently, each Java Project is packaged an independent JAR file using Eclipse's export option. Those JARs are then deployed to our Linux server manually where they are tested. If they pass testing, they are then migrated up through QA and onto Production through a home grown source code control system.

Is this the best strategy for doing batch Java? Ongoing maintenance can be a hassle since searching Jar files is not easy and different developers are creating new Java Projects (new reports) every week.

Importing existing projects from the Jar files开发者_Go百科 into Eclipse is a tricky process as well. We would like these things to be easier. We have thought about packaging all the code into 1 big project and writing an interface to be able to execute the desired "package" (aka program) maybe using a Web Server.

What are other people/companies doing out there with their batch Java programs? Are there any best practices out there on this stuff? Any help/ideas/working models would be appreciated.

---

I would say that you should be able to create one web based app for access Jasper reports, rather than a bunch of batch processes. Then, when you need to deploy a new report, just deploy a minor update that accesses a new compiled Jasper report file.

That said, you should be checking your code, not your binaries, into a Subversion or Git repository. Dump the "home grown" source control repository. Life is too short to try to home grow stuff like that. Just use Git or Subversion, they're proven, simple, and functional. When you import a new project, just pull it down from Subversion, don't try to import the JAR file from your Eclipse IDE.

Put your JAR files into a Maven repository such as Nexus, and deploy to QA and Production from there. Create automated builds for every project (be that with Maven or something else). Don't depend upon an IDE to export your JAR files. IDE's change and exporting from an IDE introduces more opportunity for human error. Also, different developers will prefer different IDE's. By standardizing on something like Maven, you're a bit more IDE agnostic.

---

Mhy company has standardized Java Batch execution using IBM Websphere Extended Deployment.

Here http://www.ibm.com/developerworks/websphere/techjournal/0801_vignola/0801_vignola.html is an article introducing techniques for programming and deploying java batch.

Introduction to batch programming using WebSphere Extended Deployment Compute Grid Christopher Vignola, WebSphere Architect, IBM

Commonly thought of as a legacy "mainframe" technology, batch processing is showing itself to be a venerable workload style with growing demand in Java™ and distributed environments. This article introduces an exciting new capability for Java batch processing from IBM®, the leader in batch processing systems for the last 40 years. This content is part of the IBM WebSphere Developer Technical Journal.

WebSphere Extended Deployment Compute rid provides a simple abstraction of a batch job step and its inputs and outputs. The programming model is concise and straightforward to use. The built-in checkpoint/rollback mechanism makes it easy to build robust, restartable Java batch applications.

The Batch Simulator utility provided with this article offers an alternative test environment that runs inside your Eclipse (or Rational Application Developer) development environment. Its xJCL generator can help jump start you to the next phase of testing in the Compute Grid unit test server.

But even if you are not interested in the product, the article is a must read anyway.