Hi, basically the properties set up java runtime and compiler compliances of the project. Code formatting properties only creep in if project specific settings are made in eclipse. If the /wicket-core/EclipseCodeFormat.xml is imported as an workspace wide formatting profile nothing is changed in those prefs.
If it were up to me I'd ignore those files just as it is indicated in the ".gitignore" file. They are not ignored by git because they existed before. But newer project do ignore em. Maybe the .ignore file can be made a little more specific as instead of: **.settings one could ignore: **.settings/org.eclipse.jdt.core.prefs **.settings/org.eclipse.jdt.ui.prefs I"ll come up with a jira an a patch of the site and the code. mf Am 28.10.2013 um 09:42 schrieb Martin Grigorov <[email protected]>: > Hi, > > > On Sat, Oct 26, 2013 at 9:45 PM, Martin Funk <[email protected]> wrote: > >> Hi, >> >> did anything evolve out of this discussion: >> >> http://markmail.org/search/?q=list%3Aorg.apache.wicket+org.eclipse.jdt.core.prefs#query:list%3Aorg.apache.wicket%20org.eclipse.jdt.core.prefs%20order%3Adate-backward+page:1+mid:uue2s7acqs3h4zuo+state:results >> >> currently if one checks out the code and ,as an eclipse user, does the >> >> mvn eclipse:eclipse >> >> as advised on http://wicket.apache.org/contribute/build.html >> >> One ends up with a big set of modified settings files: >> >> › git status >> [...] >> # modified: wicket-ioc/.settings/org.eclipse.jdt.core.prefs >> # modified: wicket-jmx/.settings/org.eclipse.jdt.core.prefs >> # modified: >> wicket-objectssizeof-agent/.settings/org.eclipse.jdt.core.prefs >> # modified: wicket-request/.settings/org.eclipse.jdt.core.prefs >> # modified: wicket-spring/.settings/org.eclipse.jdt.core.prefs >> # modified: wicket-util/.settings/org.eclipse.jdt.core.prefs >> # modified: wicket-velocity/.settings/org.eclipse.jdt.core.prefs >> [...] >> >> > New versions of Eclipse (or new versions of maven-eclipse-plugin and/or e2 > plugin) adds new settings and thus the modifications... > > The main thing is to keep the formatting of the code in your patches > consistent with the current format. The rest is not very important, I think. > > >> >> Martin
