7

I have an Eclipse workspace with many (> 50) bundles. Some bundles contains special project settings for, e.g., customer-specific code formatting.

If I set up a new workspace and checkout an existing project with customer-specific code formatting, Eclipse changes the date comment in org.eclipse.jdt.ui.prefs to the current date automatically!

This is the preference file (org.eclipse.jdt.ui.prefs) in SVN:

#Tue Apr 24 09:15:20 CEST 2012
eclipse.preferences.version=1
formatter_profile=_myProfile
formatter_settings_version=12

This is the file (org.eclipse.jdt.ui.prefs) after checkout:

#Tue Apr 24 09:30:25 CEST 2012
eclipse.preferences.version=1
formatter_profile=_myProfile
formatter_settings_version=12

The same happens with the org.eclipse.core.resources.prefs settings file if I set the encoding to UTF-8 for the whole project.

SVN:

#Tue Apr 24 09:26:48 CEST 2012
eclipse.preferences.version=1
encoding/<project>=UTF-8

After checkout:

#Tue Apr 24 09:28:00 CEST 2012
eclipse.preferences.version=1
encoding/<project>=UTF-8

If a project contains both setting files (org.eclipse.core.resources.prefs and org.eclipse.jdt.ui.prefs) only the org.eclipse.core.resources.prefs setting file will be changed!

Does someone know why Eclipse changes this line and how I can avoid it?

blahdiblah
  • 33,069
  • 21
  • 98
  • 152
Tim
  • 2,831
  • 1
  • 25
  • 37
  • 2
    Very interesting question. I don't have an answer, but one comment: it is convenient to store the settings of Eclipse in subversion, but sometimes it bites you. Subversion is only able to store complete files, and the configuration of Eclipse is part configuration, part generated or cached. – mliebelt Apr 24 '12 at 08:46
  • As to **why** Eclipse changes the date: this is the standard `.properties` file format handled by [java.util.Properties](http://docs.oracle.com/javase/6/docs/api/java/util/Properties.html). It includes the date the file was written. – Alexander Pavlov May 02 '12 at 15:11

3 Answers3

6

DO NOT store your eclipse settings in subversions!!! It doesn't allow you to have different settings or different eclipse versions. It's gonna be a real pain if you have different environments.

Consider using something like Workspace Mechanics if you want to keep your workspace settings synced.

If this only to share your format settings, export them as XML and store the XML file in your repository. Every developper could import the XML file.

noirbizarre
  • 3,429
  • 1
  • 30
  • 21
  • Thanks for your answer but - (1) generally we have a standard developer eclipse. All developers have the same version! But we need for different projects customer specific seetings. (2) Thanks for the link to Workspace Mechanics. I'll test it today! – Tim May 02 '12 at 07:15
  • 1
    Workspace Mechanics is fine... but last I checked you could _not_ have different settings for different projects. I too need to have different formatting for different projects - though in this case it is due to historical reasons... – Tonny Madsen May 02 '12 at 15:32
  • Workspace Mechanics is not an option for us! We will start to share our format settings for the whole IDE and not project specific anymore! Because of that, this is actual the correct answer for me! – Tim May 03 '12 at 11:45
1

It has puzzled me as well on a number of occasions, but I'm not so sure I can give you a complete answer.

First off, my org.eclipse.core.resources.prefs files never include a timestamp! I have other preference files - like org.eclipse.jdt.ui.prefs - that always seem to have the timestamp. In my current set-up they never seem to be unduly updated.

There are several generations of preference APIs

  • org.eclipse.core.runtime.Preferences - Accessed via Plugin.getPluginPreferences() - Deprecated in Eclipse 3.0; now simulated - Don’t use this!
  • org.eclipse.jface.preference.* - Accessed via AbstractUIPlugin.getPreferenceStore() - Superseded in Eclipse 3.1; now simulated - Used for field editors
  • org.eclipse.core.runtime.preferences.* - Accessed via Platform.getPreferencesService() - Based on an OSGi preference service

Those preferences that use the third generation of the API, reading and writing preference files seems to always happen via EclipsePreferences. This class does the "right" thing and removes the time stamp.

In some cases - e.g. in handling formatting in JDT - a special org.eclipse.jface.preference.PreferenceStore is used. This class does not do the right thing as simply write out the time stamp.

Why this class is used and exactly in which cases it is used, is not very clear from the code...

One thing is for sure though, I cannot find a way to avoid this!

Tonny Madsen
  • 12,628
  • 4
  • 31
  • 70
1

Could this be a problem with line endings? A peculiarity of your particular version of Eclipse?

I can imagine Eclipse rewriting the settings files without any apparent substantive change if the EOL character used for the file in SVN didn't match the default on the machine used for development. In that case you should only see the problem when switching machines, though. The fix would be to add an svn:eol-style = native property to the problematic files.

I limit myself to speculation on the problem because I can't replicate the behavior you're seeing, with or without mismatched line endings. I have numerous Eclipse projects with configuration files in the repo and though they're not infrequently changed automatically by Eclipse in undesirable ways, they are always substantively changed. I can't get any settings files to change only their datestamp merely by importing their project on either Eclipse Helios SR2 (which better matches the format of your settings files) or Eclipse SDK 3.7.2 (M20120208-0800). Maybe merely upgrading Eclipse would solve the problem (be sure to export your settings!).

blahdiblah
  • 33,069
  • 21
  • 98
  • 152