eclipse CDT建立project后在project name对应的目录下面会生成.project和.cproject两个隐藏文件。
eclipse java建立project后在project name对应的目录下面会生成.project和.classpath两个隐藏文件。
.project文件大小2～3K Bytes , 该文件是针对eclipse的project Description ，
.cproject文件大小是10~12K Bytes，该文件是针对CDT插件的project Description ，
.classpath文件大小有1～3 M Bytes ， 该文件是针对java插件的project Description,
.project和 .cproject , .classpath都是XML文件格式。
.project和 .cproject , .classpath 存在于project name对应的目录下，
.metadata是一个隐藏文件夹，它存在于eclipse第一次启动时指定的workspace目录下，
project name 和 workspace 分别对应的目录不能是同一个目录，否则无法建立project name。
当把project name( project name实际上就是直接产生.project) 建立在已存在source code 的目录时，
即表示该project name代表的project自动包含该目录下的所有source code。
eclipse cdt 的索引数据库文件名后缀是.pdom ，保存在.metadata/.plugins/org.eclipse.cdt.core目录下，
比如kernel_0715.1316773656364.pdom ， uboot-0715.1316772863625.pdom ，其大小很可观，从几十M 到几百M ，甚至1G Bytes。
索引数据库文件名格式一般是 [Project-Name].[Random-Number].pdom。
eclipse java 的index 数据库在.metadata/.plugins/org.eclipse.jdt.core目录下，和eclipse cdt不同，这个目录下索引文件太多了。
对一个 Workspace 配置的备份其实就是备份 Workspace 的配置目录 .metadata。
eclipse-java 在Project > Properties > Java Build Path > source下增减项目中的文件夹
今天下午遇到一个问题，Eclipse在某一个Workspace上启动CPU占用率就会是100%，
我怀疑是前两天反编译生成的一个源代码工程错误太多导致，
所以想在workspace里找到工程的配置文件然后把它删除。 经过一番尝试后发现它存在：
d:\workspace\.metadata\.plugins\org.eclipse.core.resources\.projects
下面。 把想要去掉的工程在这里面删除就可以了，这样workspace又可以正常启动了。
昨天重装下机器，由于Eclipse里面的设置让我改的乱七八糟。提示功能没有了，快捷键也给改错了（可以使用，使用后必须按下方向键向左箭头），而我又不知道怎么把他改回来。
重装系统后，安装Eclipse，然后按照找来的文章改快捷键，发现快捷键已经被改过了？！！！！Why？思考过后，发现，除了每次装Eclipse后第一次开启Eclipse时指定的文件夹一样外，其他都不一样，那好，就在那个文件夹找原因。不管是学校还是家里，Eclipse指定文件夹内肯定会有一个.metadata文件夹，那可能就是我想找到的原因。把这个文件夹里所有内容删掉（先关Eclipse），然后再重新启动Eclipse后发现，所有配置都被还原成默认，Eclipse中项目表也没有任何项目，哈，看来Eclipse内所有改动都放在这个文件夹。又学了一手，按照上一篇文章修改快捷键后，运行正常。OK。
以后Eclipse再有问题，可以直接把.metadata文件夹删除了，在进行修改。回来再研究研究这个文件夹保存的一些相关文件都是什么。
Eclipse：如何在不同的 workspace 使用相同設定
在 Eclipse 中我們可以透過切換 workspace 來區分不同的工作，
但又只保留一份 Eclipse 的程式以節省空間。
不過也因為 workspace 的設定檔是分開的，
所以當我們新增一個workspace時，常常會發現字型、排版等也都跑掉了，
如果要一一重設非常麻煩，那麼要怎麼樣才能在不同的 workspace 使用相同設定呢？
請見以下流程。
步驟很簡單，條列如下：
-
- 關掉 Eclipse
- 找到舊的 workspace 的設定檔資料夾，路徑在：${old_workspace}/.metadata/.plugins/org.eclipse.core.runtime/.settings
- 複製整個資料夾，在新的 workspace 貼上並覆蓋，路徑在：${new_workspace}/.metadata/.plugins/org.eclipse.core.runtime/.settings
- 啟動 Eclipse 並切換至新 workspace，設定是不是都回來了呢？
Sharing eclipse specific settings across workspaces:
- Go t
${old_workspace}/.metadata/.plugins/org.eclipse.core.runtime/.settings - Copy everything under the above directory to
${new_workspace}/.metadata/.plugins/org.eclipse.core.runtime/.settings
This is going to make sure that the ${new_workspace} is having the same configuration as the ${old_workspace}
Hope this helps. Update in case of any issues.
Another option is export/import:
- From your existing workspace,
File->Export...->General->Preferences, check Export all, and choose file to save them to (prefs.epf for example) - Startup Eclipse in a new workspace,
File->Import...->General->Preferences, choose your file (prefs.epf), check import all
That worked great for the original author of this tip: he had his code formatting, code style, svn repos, jres preferences imported.
Edit: On Eclipse Juno this works poorly. Some preferences silently do not carry over such as save actions.
Clean out Eclipse workspace metadata
http://stackoverflow.com/questions/11768106/clean-out-eclipse-workspace-metadata
There is no easy way to remove the "outdated" stuff from an existing workspace.
Using the "clean" parameter will not really help, as many of the files you refer to are "free form data",
only known to the plugins that are no longer available.
Your best bet is to optimize the re-import, where I would like to point out the following:
- When creating a new workspace, you can already choose to have some settings being copied from the current to the new workspace.
- You can export the preferences of the current workspace (using the Export menu) and re-import them in the new workspace.
- There are lots of recommendations on the Internet to just copy the
${old_workspace}/.metadata/.plugins/org.eclipse.core.runtime/.settingsfolder from the old to the new workspace.
This is surely the fastest way, but it may lead to weird behaviour, because some of your plugins may depend on these settings
and on some of the mentioned "free form data" stored elsewhere.
(There are even people symlinking these folders over multiple workspaces, but this really requires to use the same plugins on all workspaces.) - You may want to consider using more project specific settings than workspace preferences in the future.
So for instance all the Java compiler settings can either be set on the workspace level or on the project level.
If set on the project level, you can put them under version control and are independent of the workspace.