[GRADLE-2293] Avoid to update the timestamp in the header of org.eclipse.jdt.core.prefs whenever "gradle eclipse" is invoked and no changing is necessary Created: 11/May/12  Updated: 03/Feb/17  Resolved: 03/Feb/17

Status: Resolved
Project: Gradle
Affects Version/s: 1.0-rc-3
Fix Version/s: None

Type: Improvement
Reporter: Mauro Molinari Assignee: Unassigned
Resolution: Won't Fix Votes: 2


Whenever you invoke gradle eclipse, even if Gradle determines that there's nothing to do, it changes the timestamp in the second row of .settings/org.eclipse.jdt.core.prefs file.

This timestamp is just a comment that says when the file was last updated. If no update is necessary, it isn't meaningful to update that timestamp. Moreover (and more important!), if the project is shared in a SCM repository, updating the contents of that file when it is not necessary implies a change in the working copy of every team member whenever they refresh their project(s) with gradle eclipse, even if no actual change is made.

Comment by Dominik Stadler [ 18/Apr/15 ]

FYI, as a workaround I use the following:

	// work around unnecessary timestamp in generated file which always causes dirty files in version control
	// https://issues.gradle.org/browse/GRADLE-2293
	task adjustEclipseSettingsFile << {
	   ant.replaceregexp(match:'^#.*', replace:'', flags:'g', byline:true) {
		  fileset(dir: project.projectDir, includes: '.settings/org.eclipse.jdt.core.prefs')
	eclipseJdt.finalizedBy adjustEclipseSettingsFile
Comment by Benjamin Muschko [ 15/Nov/16 ]

As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

  • Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
  • Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

Comment by Mauro Molinari [ 15/Nov/16 ]

It Buildship is using this mechanism, I'm not seeing this problem any more. It it is not, maybe the problem is still relevant (but I never use the "eclipse" task from the command line).

Comment by Donát Csikós [ 03/Feb/17 ]

Buildship uses the Eclipse APIs to store properties so it's independent from the eclipse plugin. The impact of this problem is minimal as the task is usually executed by hand and the file generation is fast enough. Besides, most of the developers exclude the Eclipse project descriptors from the version control, so that the file changes are not visible.
Nonetheless, if somebody is still bothered by this issue, feel free to open a GitHub issue or create a pull request with the fix.

Generated at Wed Jun 30 12:18:00 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.