Mailing-List: contact dev-help@myfaces.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "MyFaces Development" <dev@myfaces.apache.org>
Received-SPF: pass (nike.apache.org: domain of lu4242@gmail.com designates
 209.85.161.53 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type:content-transfer-encoding;
        b=l3tS37kpvcb9phRcycUsoCMQOz730ZYXcWK38w6tJoVWc9qpIgLiNUe5bxEjGIHy1n
         BtLQcBjQCD8aalUq6o+iswCRkPiocOUMquL5rc7/1tqQRllfTUcGNAKBfoU/7b4vTCLr
         gpguxOYZLKt2cgsJnSgKk5Nqxua/iZOaiyb10=
MIME-Version: 1.0
In-Reply-To: <3737004005692877407@unknownmsgid>
References: <4D8B722E.3080805@gmail.com>
	<4D8B9E5F.9020709@oracle.com>
	<AANLkTi=wA39oZF9bSTgnYPg2Gi0rJ45Qppi1EWWwk7NF@mail.gmail.com>
	<AANLkTimhqPo=Fe_cp988gjrv4oVksre+4K9q8cw8frxb@mail.gmail.com>
	<4D8BB123.2040105@oracle.com>
	<AANLkTin4KLEJ=Xz=YNw9XaxUm--uMF2ZH-Bfa-ECAOyo@mail.gmail.com>
	<4D8BB92B.10504@oracle.com>
	<4D8BBC5A.9010604@oracle.com>
	<AANLkTikiV8d-5=8qqumngHvi3dWkv92Ytb6GYss9fDg-@mail.gmail.com>
	<AANLkTi=CfDg7gUnCXJRYMBVxL=GQuGTRQ_c7ir4tFD=t@mail.gmail.com>
	<3737004005692877407@unknownmsgid>
Date: Thu, 24 Mar 2011 18:01:01 -0500
Message-ID: <AANLkTi=QY6LiSzaxGB-br0Oon8iRBMm13k7S0b4Sa=MM@mail.gmail.com>
Subject: Re: [VOTE] Release of Trinidad Maven Plugins v. 2.0.5
From: Leonardo Uribe <lu4242@gmail.com>
To: MyFaces Development <dev@myfaces.apache.org>
Cc: Andy Schwartz <andy.schwartz@oracle.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

+1

2011/3/24 Scott O'Bryan <darkarena@gmail.com>:
> Is that a +1? =A0:D
>
> On Mar 24, 2011, at 4:06 PM, Leonardo Uribe <lu4242@gmail.com> wrote:
>
>> Hi
>>
>> I have created these issues:
>>
>> http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-952
>>
>> https://issues.apache.org/jira/browse/MYFACES-3082
>>
>> I agree with the proposed behavior, and I don't think do it could
>> cause any problems. So from my side there is no objections about the
>> artifacts proposed. Thanks for the clarification.
>>
>> Leonardo
>>
>> 2011/3/24 Andy Schwartz <andy.g.schwartz@gmail.com>:
>>> Gang -
>>>
>>> Looking back at the EG emails, I realize now that I dropped the ball
>>> on making sure that my proposed changes actually made it into the
>>> spec.
>>>
>>> Here was my original email ("Metadata complete jar files") from
>>> Septeber 3, 2009:
>>>
>>>> Gang -
>>>>
>>>> Section 11.5.1 of the spec defines the following annotation scanning b=
ehavior:
>>>>
>>>>> Requirements for scanning of classes for annotations
>>>>> * If the <faces-config> element in the WEB-INF/faces-config.xml file =
contains metadata-complete attribute whose value is =93true=94, the impleme=
ntation must not perform annotation scanning on any classes except for thos=
e classes provided by the implementation itself. Otherwise, continue as fol=
lows.
>>>>> * If the runtime discovers a conflict between an entry in the Applica=
tion Configuration Resources and an annotation, the entry in the Applicatio=
n Configuration Resources takes precedence.
>>>>> * All classes in WEB-INF/classes must be scanned.
>>>>> * For every jar in the application's WEB-INF/lib directory, if the ja=
r contains a =93META-INF/faces-config.xml=94 file or a file that matches th=
e regular expression =93.*\.faces-config.xml=94 (even an empty one), all cl=
asses in that jar must be scanned.
>>>>
>>>>
>>>> Since application developers have the ability to disable annotation sc=
anning at a global level, this means that any component set that wants to s=
upport this mode would need to provide a metadata complete faces-config.xml=
 file. I don't think this is a hardship for most component vendors, since p=
resumably component vendors are going to want to provide design-time metada=
ta (eg. JSR-276 metadata), which, for the moment, requires a faces-config.x=
ml file anyway.
>>>>
>>>> A question that came up here is whether we can tweak section 11.5.1 to=
 accommodate metadata complete jar files. That is, can we specify that any =
jar that contains a faces-config.xml with a metadata-complete=3D"true" attr=
ibute would not be scanned? This would allow component vendors to indicate =
that their jar files are metadata complete, and thus avoid the cost of anno=
tation scanning for the contents of the jar.
>>>>
>>>> Note that while the annotation scan is typically a one time hit (durin=
g application startup), design-time tools may end up starting/stopping JSF =
repeatedly during the development process. Thus, avoiding unnecessary scann=
ing should provide for a more efficient development experience.
>>>>
>>>> Any thoughts on whether we could/should make this change? Does anyone =
know of reasons why we avoided specifying this originally?
>>>>
>>>> Also - if we agree to make this change, is this small enough that we c=
ould get this into the the next MR?
>>>>
>>>> Andy
>>>
>>> Both Dan and Pete responded in support. =A0There were no other response=
s
>>> on the EG list.
>>>
>>> I should have followed up to make sure that the spec update happened,
>>> but apparently never did. =A0I will do that now. :-)
>>>
>>> Sorry about the confusion. :-(
>>>
>>> Andy
>>>
>