22

Possible Duplicate:
Which eclipse files belong under Version Control

We use Eclipse IDE for developing. There is always a change in .settings folder. Sometimes we are configuring something in Eclipse, but usually we change anything in Eclipse.

Eclipse changes the settings without any request of us??

What is the best practise with .settings?

Should I check in the eclipse settings (.settings) in SVN or add to ignore list?

Community
  • 1
  • 1
Kayser
  • 6,544
  • 19
  • 53
  • 86
  • 3
    It seems, [according to another of your question](http://stackoverflow.com/questions/12513277/how-can-i-configure-checkstyle-in-maven), that you are using maven. If so then you would not have to check in the `.settings` since the whole build structure is defined in the pom files. – maba Sep 20 '12 at 14:21

7 Answers7

25

The .settings directory contains – or at least should contain – vital information needed to successfully build your project inside Eclipse, such as the character encoding used for source code, Java compiler settings, and much more. If you don't commit that directory to the SCM, you will in most cases lose the ability to check out the project into a fresh workspace and immediately get it to compile. An especially sensitive aspect is the precise configuration of compiler errors/warnings. If a developer has these set up wrong, the consequences can range from frustrations by failed Eclipse builds to developers damaging code in an attempt to "fix" nonexistent errors/warnings.

Each plugin can contribute its own settings file to the directory, so feel free to pick out and ignore the irrelevant ones, retaining the important ones, like org.eclipse.jdt.core.prefs.

You do have to be very careful not to mess with project-specific settings in a way that would break the build for others. Any personal preferences should be changed globally at the workspace level, so that this configuration doesn't propagate to teammates.

One may theoretically enforce a policy where everyone is required to import project-specific settings from another place and never commit them, but that route offers no advantages and is obviously inferior in the ease-of-use department.

Marko Topolnik
  • 195,646
  • 29
  • 319
  • 436
  • I got it. Not the settings but may be some specific files belong to Mycelipse etc. Right? – Kayser Sep 21 '12 at 12:43
  • Yes, so try to leave the most important stuff (`org.eclipse.jdt.*` and such) in the SCM and be free to exclude any settings that just keep some visualization configurations and similar. – Marko Topolnik Sep 21 '12 at 12:49
  • 5
    This is really not necessary if you properly configure your Maven project (pom.xml) and use the Maven Eclipse Plugin to automatically generate these files for you... – torbinsky Sep 21 '12 at 15:31
  • 3
    For one, Maven Eclipse plugin hardcodes all dependencies in your .classpath file instead of letting the m2e classpath container manage them. Convenience is degraded in several aspects when going this route. – Marko Topolnik Apr 11 '14 at 10:49
13

Since you are using maven to manage your builds it really isn't necessary to put the .settings under source control.

By using maven you allow other IDE's to be used without being dependent on the eclipse settings.

See also Should Eclipse-specific files in an VCS be ignored, if using Maven?

Community
  • 1
  • 1
maba
  • 47,113
  • 10
  • 108
  • 118
2

It really depends on your project. This thread here should give you more than enough information to figure out what you need.

Which Eclipse files belong under version control?

Community
  • 1
  • 1
user1437891
  • 112
  • 1
  • 9
2

No need,

because different users suing different settings and config.

The setting can be described in text files

girish
  • 87
  • 4
2

As you are using Maven I would definitely say no. From my experience with the projects I've worked on, committing these files causes problems, especially if you are collaborating with people who have different environments (OSX/Windows/*nix, file system layout).

If you're not already using it, I would reccomend using the Maven Eclipse plugin (http://maven.apache.org/plugins/maven-eclipse-plugin/) to generate your Eclipse project files automatically.

Edit:

Forgot to mention that probably the biggest reason I don't like to commit any Eclipse project settings/files is because of the clutter it adds to my VCS history. I have found that these files often change for apparently no reason (i.e. preference file timestamp changes) and at best add extra changes or at worst cause annoying conflicts.

torbinsky
  • 1,450
  • 10
  • 17
  • In my experience they never change for no apparent reason. This happens only when the project is in the hands of irresponsible developers, but in that case you already have a lot of other troubles. The difference between environments is non-existent if you know how to properly set up the JRE. File system layout within Eclipse projects is, of course, always exactly the same. As for the Maven Eclipse Plugin, it's useful to manage dependencies and for little else. In fact I must disable its Maven Builder as it is unable to handle the Maven features I use. – Marko Topolnik Sep 21 '12 at 09:34
  • "..these files often change for apparently no reason.." You are absolutely right. – Kayser Sep 21 '12 at 09:39
  • @Kayser These are quite vague claims by you and torbinsky. You didn't edit the file, that much is true, but if you stop to think for a second, or look at the actual diffs, you'll invariably find a quite justified reason for the change. You could be using a misbehaving plugin, though, but then you should cherry-pick its config file only to ignore, and leave the main `org.eclipse.jdt.core.prefs` and similar. – Marko Topolnik Sep 21 '12 at 11:49
  • @MarkoTopolnik in some cases maybe you are right. But I check out the project fresh from the repository. The first thing that MyEclipse does is changing something in settings. But i will check it. – Kayser Sep 21 '12 at 12:18
  • @Kayser Now you've given a key bit of information: you are not using plain Eclipse, but MyEclipse. In all probability you'll find settings files specific to its extension plugins there. This may be the case that I describe above: it could be appropriate to exclude those quick-changing MyEclipse extension-specific files from the SCM. – Marko Topolnik Sep 21 '12 at 12:22
  • @MarkoTopolnik Ok I got the point.. Thank you very much – Kayser Sep 21 '12 at 12:41
  • @MarkoTopolnik I do typically have a lot of Eclipse plugin for my projects, so you may be right that it is the plugins and not Eclipse core that is causing most of the changes. However, the original question was asking about .settings in general, which includes plugins and their preferences as well. As Kayser had mentioned that Maven is being used, this eliminates the need to commit the .settings. As for the Maven plugin, I think you are confusing the "Eclipse Maven Plugin" for the "Maven Eclipse Plugin", which is the one that I was suggesting (see the url I included). – torbinsky Sep 21 '12 at 15:26
  • I know about this plugin, too. It will definitely not configure your compiler errors/warnings that I have singled out as one of the most important aspects of project settings. – Marko Topolnik Sep 21 '12 at 15:52
  • Good point. This is definitely a trade-off that I am familiar with. Only in my case I have found the opposite to be true: it's worth spending a few minutes to configure my compiler errors/warnings. However, to do this you need to do it at the workspace level, not the project level as the plugin will clobber your project settings. If you only have one or a few projects that can have the same settings, this works great. Otherwise, consider using separate workspaces! Also, I did find this Maven plugin: https://github.com/yonatanm/codecleaner which looks like it can set the warnings/errors. – torbinsky Sep 21 '12 at 16:13
  • Your way of doing it doesn't provide the out-of-the-box experience that Eclipse is specifically designed to support. Errors/warnings configuration is dictated by the project policy and thus should not be something that each dev is allowed to configure for himself. This leads to having a separate place where workspace-level settings are deposited, and this place is once again under version control. There is very little to gain from this roundabout approach, and the downsides are obvious. As far as that plugin, it just opens yet another Pandora's box of maintenance nightmare. – Marko Topolnik Sep 21 '12 at 16:57
  • Just a quick note, I would also not recommend committing the workspace settings to your VCS either. Aside from that, I think there have been some good trade-offs pointed out with either option. It depends on what you like maintaining more and is not a one size fits all answer. I would like to add, though, that the Eclipse core preferences does change in the .settings "for no reason" when Eclipse updates the timestamp at the top of the preference file. This can happen when someone hits "Apply" without changing anything substantial. While minor, this is something I don't like in my VCS history. – torbinsky Sep 21 '12 at 17:14
  • What would be your recommendation then to enforce project policies? Word of mouth? A Word document describing the settings? Something else entirely? As far as your point about Apply, I've tried to reproduce it just now and it is really a stretch. The only way is to actually change a setting, apply it, then change it back, then reapply. And then it comes down to a dev acting responsibly and actually **checking** what he is about to commit, reverting in case of no substantial change. In any case, I expect this to happen only exceedingly rarely, maybe a couple of times during the whole project. – Marko Topolnik Sep 21 '12 at 18:04
0

You can create best configuration and put it in SVN but this creates hell of trouble.

  1. There is no guarantee that someone will commit wrong settings and everyone will suffer
  2. Settings will need to be changed every time configuration changes happen.

It is better to put as reference if some one doesn't have any thing then he can start from it.

Amit Deshpande
  • 19,001
  • 4
  • 46
  • 72
0

The straight answer is no. Not because this file eventually changes or not but project source code repository isn't for personal file settings.

If you really need to put somewhere these IDE specific files, check-in to a separate SVN folder separate from the project.

Oh Chin Boon
  • 23,028
  • 51
  • 143
  • 215