[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[eclipse.org-architecture-council] update to naming conventions to include the .settings folder
|
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.