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

[Max Rydahl Andersen]

Gavin, I'm still wondering what it is you were thinking annotation 
processors would do better considering the rather
big limitations they have ?

/max


Max Rydahl Andersen wrote:
> 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.