New Build Tool: J2EE + Ant = JAM


News: New Build Tool: J2EE + Ant = JAM

  1. New Build Tool: J2EE + Ant = JAM (12 messages)

    JAM is a modular Ant toolkit for developing and testing Java/J2EE applications. JAM supports EJB and Servlet/JSP development using XDoclet, JUnit, Cactus, Maven, Castor and MDA/UML code generation on various J2EE servers including JBoss.

    JAM highlights include the following:
    • Uses Ant 1.6 import feature to modularize Ant tasks.
    • Uses Ant 1.6 target override feature to standardize target names (setup, gen, compile, dist, clean, deploy, test, repo).
    • Supports multi-module projects.
    • Targets EJB, Servlet/JSP, and standard Java development.
    • Promotes logical Ant property organization at the module, project and user levels.
    • J2EE application servers are interchangeable.
    • Uses Maven POM files to automate classpath and deployment drudgery.
    • Uses Maven repository to manage libraries, versioning and installation.
    • Supports transparent unit testing using JUnit.
    • Supports automated EJB testing using Apache Cactus.
    • Leverages XDoclet for EJB and WebApp deployment.
    • Supports Apache Struts development.
    • Supports MDA/UML code generation via dual source directories.
    • Supports Castor XML data binding.
    • Supports JBoss 3.x, Resin 2.x and other J2EE application servers.
    • Supports automated integration testing via the testcycle target.
    JAM is the result of two years of development and refactoring work by the Outsource Café and is published under the GNU GPL open-source license. Developers who use JAM are impressed with its ease of use and depth. Welcome to the community of JAMers.

    (NOTE: there is a name collision here with BEA's JAM tool that deals with annotations and javadoc. It is also interesting that BEA had another product called JAM (Java Adapter for Mainframe). We are running out of TLAs!)

    Threaded Messages (12)

  2. Name Collision[ Go to top ]

    Seems like the more confusing name collision is with the already existing build tool called JAM.
  3. Sorry for the confusion but you can always use the full name JavaGen Ant Modules when the issue arises. Interestingly all our other name candidates (J2EE Ant Modules, Java Ant Modules, and Java+Ant+Maven) lead to the same JAM temptation, but we are officially blaming our logo artist for making use acronym sinners ;-)
  4. Cool, more acronyms!
  5. I've got a question for JavaGen Ant Modules folks. What particular problem is being addressed by JAM that is not well-solved with Maven+Ant?
  6. Maven vs JAM[ Go to top ]

    We had originally hoped to use Maven, but we quickly realized that we’d have to rewrite many of the plugins, especially the XDoclet plugin to support requirements like dual source directories. Our Maven builds proved fragile, J2EE functionality was lacking and the documentation sparse. The other issue was lack of developer adoption and we felt that forcing already overwhelmed developers to learn yet another technology would cost us customers.

    However, having experienced the elegance of the POM and repository ideas, we decided to use these features by writing a Maven-to-Ant bridge in the form of a Maven plugin. The bridge allows JAM to provide many of Maven’s high-level services such as classpath handling, distribution packaging and version management, but from a pure Ant environment. These features along with the new Ant 1.6 import and target override functionality inspired us to refractor our Ant libraries and the results are a very cool, flexible build framework.

    We actually see JAM as step towards Maven, not as a competing framework. But until Maven matures, Ant is still the reliable industry workhorse… and we hope JAM makes it a little easier to use.
  7. Hi,

    I'm trying out maven and I didn't have to rewrite the plugins to support multiple source directories. Though I had trouble when getting the testing with cactus working when i first started.

    Its not trivial to find though I agree, but once you find it (its just a few properties that need to be changed). The maven-genapp plugin provides samples that uses XDoclet + cactus.
  8. Cactus support[ Go to top ]

    The maven-genapp plugin provides samples that uses XDoclet + cactus.
    Thanks for the maven-genapp plugin pointer, I hadn’t noticed all the examples before.

    As for as Maven Cactus goes, we had problems with the Ant tasks, not the Maven plugin. The Cactus Ant scripts are very powerful but we needed more flexibility. For example, we needed to be able to start the server or connect to an existing running server, or either run the full integration cycle (start-compile-deploy-test-undeploy-stop) or perform each step manually. Breaking out the Cactus functionality into Ant individual targets gave us this flexibility. Finally, JAM supports other test frameworks that don’t have all the cool Cactus server handling, so we had to do it in Ant anyway.
  9. I am working with a monolithic Java web application with 200k+ lines of code in 500+ Java files. I use Ant to build it and I use Maven for all the generated site documentation.

    It's been on my ToDo list for quite some time to modularize the build of the web application to help better define the dependencies in the code. For example, I want a core module, a utils module, a jsp module, a javacc module, a couple xmlbeans modules and separate custom modules to contain the code for each of our customer-specific code pieces.

    The only thing that has stopped me separating the code into modules has been that I'd either have to manually re-code the Ant script to handle the modules, or I'd have to use Maven's multiproject support (and still have to convert some of my Ant script for use in Maven), and frankly, both approaches have scared me enough to not tackle the problem until now. When I investigated JAM, it looked like a quicker and safer solution to this issue than the other approaches.

    With the help of JAM I was able to quickly and easily modularize the utils piece, and I also have JAM compiling my entire core module. I really like that I can maintain my modules' dependencies using Maven's POM and use the JavaGen plug-in to easily create a classpath.xml file for JAM's Ant modules.

    On the downside, my web application is deployed to iPlanet and Tomcat, and at present JAM does not provide a JAM appserver modules for those. I must admit that I'm impressed enough with JAM at the moment that I'm considering writing my own Tomcat appserver module, but I don't know if I have the luxury to do that at this time. Also, there are no JAM modules ready-made to handle my JavaCC and XmlBeans needs.

    Nevertheless, if nothing else, JAM has started to show me how to fully utilize the new capabilities of Ant 6.1 to create a modular and flexible build system for my multi-module application.
  10. Incremental Release?[ Go to top ]

    Can I do an incremental release using this JAM tool?

    i.e Only updated files ( mostly JSP/property/Jar files ) needs to be created for distribution to different environments ( dev/test/production )

  11. Incremental Release?[ Go to top ]

    The short answer is not yet. However, JAM was built as a foundation for doing this sort of thing, so it’s in the works.

    By the way, this is actually easy if you’re working with a networked file system, you just use the copy task and it only copies newer files. Updating files to a remote server is another matter, you have to use SCP (SSH copy) and I don’t know how you check individual file timestamps on the server. Anybody know?

    JAM does supports incremental build and testing at the module level, you can look at the EJB module in the Petstore demo ( to see how its done.
  12. javagen on OS X[ Go to top ]

    Should the build.xml template work on OS X? I'm having problems getting the Javagen build.xml file to work under OS X 10.3.3, because of the Ant task <property>.

    In the standard build.xml, Javagen makes use of an environment variable called JAM_HOME. From the User's Guide:
    Must be defined in each build file before the import statements so Ant can find the JAM modules. To avoid hard-coding, the JAM location define JAM_HOME as an environmental variable pointing to the directory you installed JAM in. Then include the following two lines above your import statements:
      <property environment="env"/>
      <property name="jam.home" location="${env.JAM_HOME}"/>

    Altough this works fine on WinXP, "env" doesn't seem to be doing the right thing for me on 10.3.3, so "jam.home" doesn't get set properly. Reading up on the <property> task for Ant, I see this note about the environment attribute for the property element:

    ...the prefix to use when retrieving environment variables. Thus if you specify environment="myenv" you will be able to access OS-specific environment variables via property names "myenv.PATH" or "myenv.TERM"....This functionality is currently only implemented on select platforms. Feel free to send patches to increase the number of platforms this functionality is supported on ;).

    I can't tell what the "select platforms" are, so I'm wondering if Javagen has been used on Mac yet. It's been very useful to me on XP for the last month, so thanks!
  13. javagen on OS X - Patch[ Go to top ]

    There are only a few references to the 'env' property, which can be overridden to easily solve this problem. Just hard-code the following property declarations early on in your build file (changing the values to match your setup):

    <property name="jam.home" location="/dev-tools/jam"/>
    <property name="maven.home" location="/dev-tools/maven-1.0"/>
    <property name="jboss.dist" location="/dev-tools/jboss-3.2.3"/>

    Hope this helps...