[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 |
Description |
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. |
Comments |
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:
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. |