[seam-dev] Re: Getting more out of annotation processors

Max Rydahl Andersen max.andersen at redhat.com
Mon Jun 1 03:04:22 EDT 2009


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.
>
>    



More information about the seam-dev mailing list