[eclipse.org-architecture-council] update to naming conventions to inclu

[David M Williams <david_williams@xxxxxxxxxx>]

I have updated the Eclipse Naming Conventions,
see 

http://wiki.eclipse.org/index.php/Naming_Conventions

to include the following information
about names of files in the ".settings" folder. 
I suspect this sort of obvious to most,
but I thought it best to write it down, and 
enforce it the same as with the other
naming conventions. 

I'm partially doing this because I'm
insisting one of our WTP teams change our use of ".component"
filename ... so, 
if we are doing that, wanted to be sure
everyone else was being good citizens too:) 

If anyone has any issues/problems/questions/suggestions
.. feel free to edit the wiki page! 

If anyone knows of any obvious violations
(besides ours :) I would be interested to know that too. 




System Files and Settings

By convention, files or folders that start with a period ('.') are considered "system files" and should not be edited by users or, directly, by other components that do not "own" them.

Of special note is the ".settings" folder in a workspace project. This folder holds various forms of preference or metadata specific to that workspace project. Files in this directory do not have to start with a period (they are assumed "system files" as they are in a "system folder") but they must follow the same naming conventions outlined elsewhere in this guide. That is, they must identify themselves with their Eclipse Project's namespace (e.g. org.eclipse.jdt, org.eclipse.jst, etc). and they should be as specific as possible to denote the package they come from, or the function they are serving. For example,

 org.eclipse.jdt.core.prefs
org.eclipse.jst.common.project.facet.core.prefs
org.eclipse.wst.common.project.facet.core.xml

Two obvious exceptions to this convention are the .classpath and .project files, but ... that's just because they were the first, before the large community of Eclipse was grasped. Following these namespace guidelines will help avoid conflicts where two plugins or projects could accidentally pick the same name for a metadata file.