Wouldn't Geronimo specific annotations lead to porting problems? Having developers to edit and recompile source files inside App Server independent Java EE archives, whenever they want to port their apps from one App server to another, would be cumbersome. Isn't it?
Rather than coming up with Geronimo specific annotations, why not put the same effort in automating the generation of Geronimo specific deployment plans. This could be achieved by scanning the corresponding Java-EE plans/annotations and then running the user through a Wizard where he can specify the missing data. I will start a separate thread on this. Others please comment. Finalizing on this would help us to concentrate on developing the required features in Geronimo Eclipse plug-in. -- Thx, Shiva On 11/29/06, Sachin Patel <[EMAIL PROTECTED]> wrote:
What are people's thoughts on annotation support we should provide in Geronimo 2.0? I'm not referring to the spec annotations, but container specific annotations (configuration in our g-deployment plans). From a users perspective, our deployment plans are massive and one of the options to simply using them is through annotations. Is this something people agree on? If so, then we need to have the XDoclet / JSR-175 debate. From my viewpoint, XDoclet is a legacy technology with the introduction of JSR-175. There are misconceptions that XDoclet still plays a role in that its purpose is a code-generation facility and JSR-175 cannot be used for this purpose is not the case. With JSR-175 and Sun's APT code/xml generation can be done as well. (Even though its much more complex to do). I'd like to provide XDoclet support in Geronimo 2.0 as its the easier solution, however my concern is that JEE 5 Developers will not want to deal with mixed type annotations. Do people see this as a valid concern? Or should our approach be Geronimo Specific 175 Annotations, that can either generate xml or introspected during runtime as an alternative dealing directly with the deployment plans. -sachin
