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