JAG is a java application that creates complete, working J2EE applications. JAG has a pluggable business/persistence layer and the new 4.0 release adds support for EJB3 and Hibernate 2.1.

Features

One of the strengths of JAG is that it delivers a complete working project - it's more than just another code generator! The projects generated by JAG have the following features:

• A full, professional quality project infrastructure: The generated applications build with Apache Ant and have a flexible, well-organised directory structure.
• By choosing from JAG's extendable framework of 'application templates', you have control to select the most appropriate application architecture.
• Best-of-breed J2EE architecture: The various application architectures are derived from a real-world appreciation of industry best practices.
  The latest application template offers:
      
  • A strict enforcement of presentation-layer
    separation using interfaces to enable the greatest flexibility in
    deployment scenarios
      
  • EJB 2.0 features such as container-managed relations.
      
  • J2EE 'BluePrint' patterns such as Session Façade, Service Locator, Business Delegate, Fast Lane Reader and Value Objects.
      
  • A pluggable business/persistence tier: EJB2, EJB3 or Hibernate 2
      
• A presentation layer (web application) that takes advantage of the latest features of Struts, such as declarative client- and server-side user input validations, and clean, modular JSPs using Struts and the display tag library.
• Extensive use of XDoclet in the generated application means that the complexity of the code base is vastly reduced, increasing maintainability. Through the
  use of XDoclet tags in the generated Java code, many of the JAG-generated classes
  serve as a basis for further automatic code generation at build-time!

EJB3 is supported for the JBoss4.0 application server with EJB3.0 Preview Release 2.

Since JAG also supports EJB2 using xdoclet, it's interesting to see how all xdoclet markup is obsolete for the EJB3 release now!

Visit the JAG home page: http://jag.sourceforge.net

what a nice code generator ! thanx a lot for creating it !

Would be interesting to see Axis or some other Web Services framework support integrated with the generation.

The concept of generation is a powerful one for boot strapping a new application. The only tricky business with the generation is integrating with an existing system.

Since it uses Struts this can probably be achieved by creating a seperate module or set of actions that represent the new functionality that will be used by an existing application. It does depend on the level of integration though.

Looks like a nice generation framework will have to try it out. Thanks for the post.

Would be interesting to see Axis or some other Web Services framework support integrated with the generation.

As a matter of fact the support for exposing the service layer as a web interface is on our wishlist.

The only tricky business with the generation is integrating with an existing system.

Integrating the generated business/persistence layer shouldn't be that hard, since we use a strict service layer using interfaces only. You can easily drop the generated struts web application and use the service layer from an existing application.

cheers,

Rudie Ekkelenkamp.

Looks good! Very impressive.

I note that the generated code is abstracted into the usual layers just as if the code was being hand-written.

I find this interesting because one of the benefits for me of code generation is that the variability in the system moves from the source code back to the specification + generator.

This means that it should be possible to generate 'raw' code, ie no need in principle for abstract superclasses or interfaces unless the business design requires it. You could even take it further and say no need for any framework, ORM, CMP. No need for compile-time type-safety since object relationships are generated by the same item in the model.

There are so many tools aimed at mitigating the complexity of writing J2EE apps by hand. But these tools shouldnt be necessary for code generators because it is the generators that handle the complexity.

I dont mean to criticise, and I guess the layers are very important if the aim is to produce an initial system that a coder will tailor by hand.

As I say, very impressive!
Kit

Thanks for your feedback. I would like to comment on the following:

.This means that it should be possible to generate 'raw' code, ie no need in principle for abstract superclasses or interfaces unless the business design requires it.

It would be possible use the generated "raw" code of course, but we prefer to keep the abstraction of interfaces. This allows us to use the same front end implementation for all business/persistence implementations.
Also, for a front end developer the persistence layer will be consistent, no matter which persistence technology will be used. And for the business logic developer, the raw code is available to implement their business methods (exposed as interfaces) of course.
And finally using interfaces allows you for convenient implementation of a mock service next to the actual service. This can be very handy for the front end developer to start working using a mock implementation.

We use for generate application skeleton AppFuse ( - overwhelmed).

Is JAG comparable with AppFuse ? Is anywhere on Internet some demo application ?

We use for generate application skeleton AppFuse ( - overwhelmed). Is JAG comparable with AppFuse ? Is anywhere on Internet some demo application ?

I must admit I did not know the AppFuse generator. I apoligize if my conclusions are wrong, bu a quick look suggests it focuses on web layer generation using spring and hibernate for persistence. JAG on the other hand currently only supports struts 1.1 but for persistence you have the choice in EJB2, EJB3 and Hibernate.
JAG also targets at creating a complete build environment from which you can build, deploy, junit test...
And finally we think JAG has a very intuitive GUI which allows for many configurations. And if you don't like the GUI, you can use UML just as well.

Rudie Ekkelenkamp.