However, I'm pretty much all confused about what previous mapping strategies still apply and how this all is supposed to work. I'll try to break down what options (context params) I've seen discussed. Whatever here is deprecated, would be good to know. And actual scenarios, with all needed configs, would be a great help.

Generic resource mapping enabled: "org.richfaces.resourceMapping.enabled", value "true") - seems this may now be deprecated/unnecessary, but not sure.

Generic (dynamic resource override?) resource mapping location: Root of where resources are located - with a suggested path of "#{facesContext.externalContext.requestContextPath}/resources/#{resourceLocation}" - the root location of your local resource libraries, like js, css, etc.

Static resource mapping properties file: "org.richfaces.staticResourceLocation.mappingFile", pointing to properties file location - suggested path of "/META-INF/richfaces/static-resource-mappings.properties". Seems this may or may not be necessary if a file called "static-resource-mappings.properties" is anywhere in your classpath, or is it deprecated altogether?

Static resource mapping location: "org.richfaces.staticResourceLocation", with a suggested path of maybe just "#{resourceLocation}", eg, for CDN. Is this even necessary anymore or is it deprecated? See https://community.jboss.org/message/591640#591640

It might also be helpful for me to clear up whether "static" here means a static location or static loading, or both, and whether mapping -- using any strategy -- a default, dynamically loaded resource to a static location turns it into a static resource (ie, it will be loaded regardless of what components happen to be in the page).

Finally, although mapping and optimization have now been split apart, I'm still wondering whether it will be effective in RF during deployment, when packing and compression s/b enabled. Because, for example, packed.js (which is already built in the jar) contains a full version of jquery.js, so if I'm pointing jquery.js to a CDN in my mapping file, won't the CDN script file collide with the version in packed.js in a deployment environment? Can this strategy only work if packing is disabled, or if I make a custom packed-patched.js, with jquery.js removed?

3) Generic (dynamic resource override?) resource mapping location: Root of where resources are located - with a suggested path of "#{facesContext.externalContext.requestContextPath}/resources/#{resourceLocation}" - the root location of your local resource libraries, like js, css, etc.

Is not needed anymore in 4.2, the sensible default was provided in order to serve both features Resource Mapping and Resource Optimization.

4) Static resource mapping properties file: "org.richfaces.staticResourceLocation.mappingFile", pointing to properties file location - suggested path of "/META-INF/richfaces/static-resource-mappings.properties". Seems this may or may not be necessary if a file called "static-resource-mappings.properties" is anywhere in your classpath, or is it deprecated altogether?

As answered in (2), you have two options: configure own mapping file with context-param (more in the docs) or just use the default one (when provided in classpath, it will be used).

5) Static resource mapping location: "org.richfaces.staticResourceLocation", with a suggested path of maybe just "#{resourceLocation}", eg, for CDN. Is this even necessary anymore or is it deprecated? See https://community.jboss.org/message/591640#591640

It might also be helpful for me to clear up whether "static" here means a static location or static loading, or both, and whether mapping -- using any strategy -- a default, dynamically loaded resource to a static location turns it into a static resource (ie, it will be loaded regardless of what components happen to be in the page).

RichFaces Resource Mapping is dealing just with locations, so static means "static configuration of resource location".

Finally, although mapping and optimization have now been split apart, I'm still wondering whether it will be effective in RF during deployment, when packing and compression s/b enabled. Because, for example, packed.js (which is already built in the jar) contains a full version of jquery.js, so if I'm pointing jquery.js to a CDN in my mapping file, won't the CDN script file collide with the version in packed.js in a deployment environment? Can this strategy only work if packing is disabled, or if I make a custom packed-patched.js, with jquery.js removed?

In RichFaces 4.2, jquery.js is completely separated from packed.js, so you can point it to CDN how it is documented (refer to answer to (5)).

I responded to your reply to my other, similar post. I truly appreciate your detailed responses, and think I'm clear on everything now. I'm not sure whether everything's working as expected (particularly with the default static mappings properties file), but will test again once I update from CR1 to Final.

Your explanation of "static" resources is also very helpful. I'm understanding that it entirely depends on the particular project's needs as to whether one can successfully use built-in RF resource optimization, since there is no "real-time" or dynamic resource compression and packing. Essentially, if I really need to customize resource mapping, I may have to rely on using a maven plugin, like the one RichFaces has, for compile-time optimization, which is fine.

A note that might be useful to others. This Servelt filter has been working really well for me, to deliver compressed files over HTTP request: http://sourceforge.net/projects/pjl-comp-filter/. I still have to customize my configuration, and maybe configure server-side caching of already-compressed resources, but this is working for me right out of the box.

OK, so for all of my local resources, they are placed in "library" folders underneath the "resources" folder of my app's WebContent, as per JSF 2.0 spec.

If I call, for example <h:outputScript name="js/richfaces/a4j.js" target="head"/> or <h:outputScript library="js" name="richfaces/a4j.js" target="head"/> it loads correctly, since a4j.js is loated in the path /resources/js/richfaces/a4j.js.

EDIT: However, it tries to load twice, once with the path that doesn't exist and once with the correct path (or what looks like once from the mapping file and once from the h:outputScript call).

When I was using custom mapping, defining the mapping location (the old way), and just plopping an a4j tag in the page, the file was loaded correctly, and then, using mappings like org.richfaces\:status.js=a4j.js also worked, and by pointing all a4j-specific scripts to that same local resource, I avoided duplicate loading.

I'm basically just trying to figure out why that's not the same behavior for the default mapping.

And because it's the same path for all three calls, there are no duplicate calls. If I remove the re-mapping of the primefaces jquery.js (which is technically unnecessary), for example, that leads to the script being loaded twice in different places, which causes ordering problems.

I'm just playing around with this for now. The working solution for me is to keep all mapped files either local or pointing to a full URL (like a CDN). Trying to add mapping from one library's resources to another's (except as above) just doesn't seem to work correctly.