JAG (http://jag.sourceforge.net) is an application that creates complete, working J2EE applications. JAG now generates an improved J2EE architecture using a service locator and dynamic business delegates to access session EJBs. The web layer is decoupled from the EJB layer using interfaces.
Also an improved web application is generated using the displaytag tag library which greatly improves the generated tables with paging,
sorting and export functionality.

CHANGES for JAG 3.4
=======
1. Added templates for the Entity and Session template in Bea Workshop EJBGen format.
   EJB layer can be generated for Bea Workshop.
2. Added templates for a simple maven project
3. Major architecture change: decoupled web layer from EJB layer with interfaces.
   Introduced a service layer. Use a service locator with
   dynamic business delegates for Session EJBs.
4. Added EJBQL finder methods on the Entity EJBs so for every field a findByFieldName
   is generated. These methods are exposed in the session facade as well.
5. Support for JBoss 3.2.0-1 and JBoss 3.2.2-7 where handling of commons-logging was
   changed.
6. Foreign keys can be primary keys now.
7. Refactored template directory and changed .jag into vsl extension.
8. Added path for service sources and for conf files. Removed webXml and ejbXml paths
9. Generated web application uses the displaytag tag library which greatly improve
   the generated tables with paging, sorting and export functionality.
10.Updated sample application for mysql that can be deployed to JBoss4 without creating
   a database schema. The default test database is used. Also sql script for mysql
   and postgres are provided.

Why somebody would want to use JAG instead of MDA or Middlegen?

good question, does it support cartridge functionality? If it didn't use EJB and I could create a spring cartridge and use valuelist instead of displaytag.

JAG supports selecting a set of velocity templates, which i suppose could be called a cartridge. So you can easily adjust the templates for your own needs and use them to generate a J2EE aplication.
As far as the spring framework is concerned, we are planning to support that in a future release.

Well,

Why use JAG? In my opinion the big advantage of JAG is that it creates a complete project with a clean design for you that can be build and deployed including all configuration files you might need for you application server. Jag is intented to get you quickly started with a J2EE project, not to model all you business logic like with MDA technologies like AndroMDA. JAG dus support UML though, but just for modeling de Entity and Session EJBs..
JAG also has support for JBoss4, Weblogic 8.1 and SunOne Application Server 7, which isn't supported by most other tools.

In my opinion the big advantage of JAG is that it creates a complete project with a clean design for you that can be build and deployed including all configuration files you might need for you application server. Jag is intented to get you quickly started with a J2EE project,

Middlegen seems to be doing exactly the same. Does it?

Doesn't middlegen generate code from a relational schema? There are a few competitors in that area, but I don't think JAG is one of them.

Doesn't middlegen generate code from a relational schema? There are a few competitors in that area, but I don't think JAG is one of them.

Well, JAG is one of them as well. The intended use of JAG is to start with a database schema. You connect to your favourite database, select the tables that should become entity ejbs, and you add session facades in front of them. That's all you have to do.

There is indeed quite some overlap between JAG and Middlegen. As far as the generated code, IMHO the resulting code of JAG is more suitable to start working on the generated project.
For example, the web struts/jsp layer only uses interfaces from a service layer to access the business layer. It is very easy to implement a different service implementation. We use it for example to create a mock implemenation that can be used for testing the webinterface.
With Middlegen the EJBs are called directly from the struts actions which makes the web layer dependent on EJBs.
Also JAG generates the validations for the forms using the struts1.1 validator framework. As far as I know, middlegen doesn't do that.
And we thing the JAG Gui is realy intuitive for getting a project started really fast.

Also an improved web application is generated using the displaytag tag library which greatly improves the generated tables with paging,sorting and export functionality.

I hope you do realize the displaytag makes your application non-scaleable by requiring you to cache your lists.

We realize that using displaytag is not the most scaleable solution, but we think it is an attractive web layer presentation. If you need a more scaleable implementation for displaying lists, it is quite easy to change this, since the generated business implementation of JAG supports displaying stepped lists.

The valuelist project does have better architecture than the displaytag. valuelist also performs much better when paging in involved. JAG should have done some homework before integrating the displaytag component. Or did the JAG team have a good reason for [picking the displaytag component?

We did do our homework though :-)
We intend to keep the generated application as simple as possible and the displaytag component seemed to be the easiest to use and best known component. Supporting the valuelist handler design pattern as default, makes the generated code more complex. But I could imagine to make it an option for a future release of JAG.

As part of the ValueList team and an understanding of both products, I understand why they choose displaytag. Displaytag is a good product, it has a clean seperation between the display layer and others.
  To use the best features of valuelist cleanly you must introduce valuelist in both your presentation and dao layer. You do get great benifites from valuelist, but at a greater cost.

The valuelist project does have better architecture than the displaytag. valuelist also performs much better when paging in involved. JAG should have done some homework before integrating the displaytag component. Or did the JAG team have a good reason for [picking the displaytag component?

How can I extend JAG to generate code for my custom architecture using XMI UML Model. I understand JAG currently supports only entity and session beans from the UML model. Is there a way that JAG can figure out the type of object(Pojo, Struts action, actionform etc) from the UML model and associate it with the corresponding template in the templates directory of JAG for generating the code.
Thanks,
Siva

How can I extend JAG to generate code for my custom architecture using XMI UML Model. ...

Why do you want to extend JAG if AndroMDA is supposed to do exactly what you want? ( http://www.andromda.org/andromda-cartridges/index.html )

JAG can be extended by adding or changing the Velocity templates or sources from the code generation directory. JAG can not be used to model Pojo's and struts actions from the GUI or UML. We want to keep the usage of JAG as easy as possible and are not trying to make it a MDA tool like AndroMDA which requires much knowledge about the UML profiles of the different cartridges.

I checked out JAG.It is good stuff . However , there ar supreior alternatives to entity beans. Your next version should use:
1) Hibernate/ Ibatis/ Cayenne
2) Spring
3) AOP -- for transaction, logging and securtiy

The rest looks good!

Good to hear you like most of it! We are actually planning to support Spring/Hibernate in a future release.
And entity ejbs will be migrated to the EJB3 version, which seem te be a lot better.