[jsr-314-open] Metadata complete jar files

[Andy Schwartz]

Gang -

Section 11.5.1 of the spec defines the following annotation scanning 
behavior:

> 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 “true”, the 
> implementation must not perform annotation scanning on any classes 
> except for those classes provided by the implementation itself. 
> Otherwise, continue as follows.
> * If the runtime discovers a conflict between an entry in the 
> Application Configuration Resources and an annotation, the entry in 
> the Application 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 jar 
> contains a “META-INF/faces-config.xml” file or a file that matches the 
> regular expression “.*\.faces-config.xml” (even an empty one), all 
> classes in that jar must be scanned.


Since application developers have the ability to disable annotation 
scanning at a global level, this means that any component set that wants 
to support 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 presumably component vendors are going to want 
to provide design-time metadata (eg. JSR-276 metadata), which, for the 
moment, requires a faces-config.xml 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="true" 
attribute would not be scanned? This would allow component vendors to 
indicate that their jar files are metadata complete, and thus avoid the 
cost of annotation scanning for the contents of the jar.

Note that while the annotation scan is typically a one time hit (during 
application startup), design-time tools may end up starting/stopping JSF 
repeatedly during the development process. Thus, avoiding unnecessary 
scanning 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 
could get this into the the next MR?

Andy