. classspath 和. project-签入版本控制还是不签入？

Definitely no - it's generally terrible idea to distribute project files via subversion. Especially since someone might modify them in a some strange manner. A good page in the project's documentation is a much better idea. Our project also has many modules and a complex setup. We've set up a confluence page describing how to get started with the project on each populer IDE - IntelliJ, Eclipse, NetBeans. A README file in Subversion contains the same info.

I would check theese files in to make the start for new users as easy as possible. At best the user should check out the project and should be able to run it without extra knowledge. For this files the rules are the same as for other files in the project: handle them with care. You should not place absolute pathes in the source code, neigther you should in the configuration files.

If the files are checked in in a way that the project runs from scratch there should not be much forces to change them.

I would recommend that you check the files into subversion IF they do not contain absolute paths and other data which would tie them directly to a single developer's environment.

If the files do contain absolute paths and the like, a README would be a better choice.

Yes, definitely check them in, but make sure that you document any path dependencies and avoid absolute paths if possible.

If you don't check them in, then anyone checking the project out will need to recreate all of those settings, which is annoying and potentially error prone.

Some complex setups may be better handled by a script to generate these files, but usually it is better to just check them in.

Definitively yes, as I said in "Do you keep your project files under version control?"

"Load it up, set it up, go."

But... this is actually true only for recent Eclipse3.5 settings, where build paths support relative paths:

And Eclipse3.6 would be better, as it supports relative paths for path variables in Linked Resources:

(since 3.6M5)

I vote no, but that's because I would generally generate these files from maven

In my experience, excluding the limited cases where purely local settings are involved, everything should be in source control. The law of source control is that everything pushed in should be expected to work by those who pull out. Unfortunately, eclipse often causes things like this to be in .classpath:

    <classpathentry kind="con"
path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.launching.macosx.MacOSXType/Java SE 7"/>

So on my Mac this works, and maybe someone on a Mac has the same JRE, but this will not work for anyone else.

Also, there's no easy way around this. Eclipse will always add that in. I WANT to have the .classpath file in there, because there are some 3rd party JARs in our lib folder where we care about versioning, so we leave them in there so new developers do not have to get them. We're moving to a managed system, but still have managed+unmanaged dependencies checked in. This means all the developers just have to ensure two directories are in their .classpaths. But it's better than having to fix your JRE every single time you pull and have a change in your .classpath every single time you commit.

Eclipse does some other nice things for you though. The .project file will usually be the same across instances, so include that. But the best thing about source control for eclipse is the Run Configurations settings. Under the "Common" tab in the Run Configurations dialog, save the configurations so they appear for your colleagues under the favorites lists for Debug and Run. For me, a bunch of .launch files go in the .settings directory, so we can all use them.

So I say: .settings directory goes into source control for launch configs (except *.prefs)

.classpath stays out

.project goes in.