Just be aware annotation processors have one big limitation...it will only generate code based on *source*, not on available classes in the classpath. This make it impossible (or at least very hard and clumsy) to use on projects that have i.e. entities in one project, dao in another and view in a third. i.e. each "module" can generate their 'piece', but if you want the annotation processor to generate something based on 'cross-module-info', i.e. take the entities+dao to generate a matching view layer then you are limited to guessing what is in one of the two... I realized this limitation when I wanted to try to generate a graph of webbeans dependencies, I wouldn't see any of the already compiled and dependent named beans from i.e. the core, making it a rather boring graph ;) /max Gavin King wrote: > Folks, as we start work on Seam3, and the tooling for Seam3, we need > to look out for opportunities to get more out of annotation > processors. They can help us solve certain problems that we weren't > able to easily solve in the past. > > One thing I would definitely like us to do is DAO generation. What I'm > thinking of is like a next generation version of the "framework" > package in Seam. For example, for each entity like Customer we could > generate a class CustomerHome extending EntityHome and adding typesafe > finder methods (findByName() and friends). Of course, the user could > extend and specialize this generated class to override or add extra > functionality. > > It would even be possible to generate JSF composite components for > each entity, i.e.<e:displayCustomer/>,<e:editCustomer/>, > <e:displayCustomerAsRow/>. > > Of course, all this would need to work nicely in Eclipse.