G specific annotations for 2.0, XDoclet or 175?

[Sachin Patel <sp...@gmail.com>]

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

Re: G specific annotations for 2.0, XDoclet or 175?

[Matt Hogstrom <ma...@hogstrom.org>]

Is this issue still on the table?  I haven't seen any specifics.  In  
general I'd prefer to stay away from G specific stuff and leave them  
in deployment plans.  However, if we make them available they should  
be totally optional and users can make their own choices.

On Nov 29, 2006, at 11:18 AM, Sachin Patel 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
>
>

Matt Hogstrom
matt@hogstrom.org

Re: G specific annotations for 2.0, XDoclet or 175?

[Shiva Kumar H R <sh...@gmail.com>]

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 <sp...@gmail.com> 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
>
>
>