Mailing-List: contact dev-help@myfaces.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "MyFaces Development" <dev@myfaces.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
Subject: Re: Result (Was Re: [VOTE] Add MyfacesBuilderPlugin to buildtools
	branch and use it on myfaces 1.1)
From: simon <simon.kitching@chello.at>
To: MyFaces Development <dev@myfaces.apache.org>
In-Reply-To: <f6c92360804251739h4ad60338ybea8ab37f6dd58f0@mail.gmail.com>
References: <f6c92360804251633w18e80921x247670ee197327a8@mail.gmail.com>
	 <bc36a6210804251652t69bc1af9s28d670859a24b14d@mail.gmail.com>
	 <f6c92360804251739h4ad60338ybea8ab37f6dd58f0@mail.gmail.com>
Content-Type: text/plain
Date: Sat, 26 Apr 2008 21:03:27 +0200
Message-Id: <1209236607.6164.14.camel@simon-laptop>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit


On Fri, 2008-04-25 at 19:39 -0500, Leonardo Uribe wrote:
> 
> 2008/4/25 Andrew Robinson <andrew.rw.robinson@gmail.com>:
>         Forgot to ask, this uses annotations for JSF >= 1.2 right?

Yes.

Well, actually it is user's choice, as both are supported. But I would
imagine that people would choose real annotations when available.

>         
>         Also one more question, would Jsf* be better than JSF* for the
>         names
>         (ie JsfProperty vs JSFProperty)? Using all uppercase for an
>         acronym in
>         a java name is not conventional. Uppercase is usually reserved
>         for
>         starting a new, unabbreviated word.
> 
> Yes, I have seen this too. The convention on xdoclet is use
> namespace.prefix. I would like to use something like this:
> 
> oam.Component
> oam.Converter
> oam.Validator
> oam.RenderKit
> oam.Renderer
> oam.Property
> oam.JspProperty
> oam.JspTag
> oam.JspAttribute
> oam.Exclude
> 
> or something like that. I would like to see what Simon thinks about
> this, since he proposed the names at start and I don't know if he has
> a particular reason about the choice of the tags.
> 
> Simon: What do you think about this?

I would suggest that it is nicer to have the javadoc tags and real
annotations use the same names. A class obviously cannot have "oam." in
the name. Possibly the real annotations could have the above names with
the "oam." stripped off. However in at least some cases, the result
seems a too-generic name to me. For example, @Property or @Component
aren't immediately obvious when reading the code, and may clash with
other libs (doesn't Seam have @Component already?).

I think in Eclipse, using a dot name for a javadoc tag also makes the
spelling-checker mark the name as a spelling mistake, which is mildly
annoying.

If people want JsfComponent rather than JSFComponent, I'm ok with that.
But Sun went to the effort of actually deprecating getUrl() in favour of
getURL(), so presumably the all-caps-for-acronyms is a java convention. 


> 
> On myfaces 1.2 maybe annotations could not be used, because maybe it
> breaks the TCK, but I'm not tested this yet, so its a point to take
> into account. The actual code allows to use annotations and doclets
> (we need to update annotation classes).

I think it *very* unlikely that annotations would conflict with the TCK.
These are source-retention annotations only, ie have absolutely no
effect on the generated .class files.

So if this plugin is used with myfaces 1.2.x, I would recommend real
annotations be used and not doclet tags.

Note that using qdox to scan source for annotations is actually *easier*
than using APT for it, for several reasons. The APT tool is really ugly
to use. So there is no reason to think of the myfaces-builder-plugin as
having a "legacy" architecture just because it also supports doclet
tags.

Regards,
Simon