At work we all share the same Eclipse settings, and this works quite well, even with different versions of Eclipse. Officially we all use 3.6, but some of us still use 3.5 or even 3.4. You will get some problems, as the formatting in these versions is slightly different (for example, 3.6 is finally able to format annotations), but for most of the code the formatting is fine.
Do you mind if I configure wicket-security to automatically use these settings files when used with the maven-eclipse-plugin? The people I know of that work on wicket-security, all use the maven-eclipse-plugin with a recent version of Eclipse. By the way, I did some more coding on wicket-security yesterday, and pulled your reformatting commits, and had some conflicts. I resolved the conflicts and committed, and git created a massive "Merge branch 'master'" commit, containing all changes on wicketstuff for the past few days. Is this normal behavior? And is there a way to prevent this? It looks a bit awkward in the commit history. Emond On Tuesday 12 April 2011 20:13:49 Attila Király wrote: > The solution I proposed and comitted (see readme and files in > https://github.com/wicketstuff/core/tree/master/config/eclipse) only allows > a workspace level manual configuration (import 2 xml, configure some > options). > > I dont know what maven-eclipse-plugin can do I always used m2eclipse for > maven-eclipse voodoo. Note however that some of the argument against > storing .settings in the repo came from Eclipse users who feared that it > can mess up different Eclipse environments using different plugin sets > (for some degree I had experienced this in the past in some of my own > projects). So any kind of IDE configuration needs to be activated manually > and not automatically to keep everyone happy. > > Attila > > 2011/4/12 Emond Papegaaij <[email protected]> > > > I know I'm too late to vote, but still +1 > > > > With the IDE specific files in the top level of the repo, would it be > > possible > > to configure the maven-eclipse-plugin to copy these files to the > > .settings dir > > of every java project? I think it possible to configure this in the > > parent pom, so it will be applied to all Wicketstuff projects, and work > > automagically > > for everyone using the maven-eclipse-plugin. Perhaps something similar is > > possible for other IDEs/setups? > > > > Best regards, > > Emond > > > > On Friday 08 April 2011 16:46:19 Attila Király wrote: > > > Hi! > > > > > > A lot of responses were posted and there was also some talk on IRC > > > about the previous suggestion. Cool! I feared that the discussion will > > > boil > > > > down > > > > > to tabs vs spaces or to where to put the braces. :) Luckily that was > > > not the case. > > > > > > It seems there was only one area which was not liked by some: to put > > > Eclipse's .settings directory into the repo. There were several ideas > > > > about > > > > > how to accomplish auto code formatting, cleanup in an IDE independent > > > way but there was no consensus. > > > > > > But on the bright side no one complained about adopting wicket style as > > > > the > > > > > common format. Peter Ertl mentioned some difficulties about IDEA and > > > javadoc formatting but if that is all Imho we can live with slightly > > > inconsistent javadoc formatting for now. > > > > > > So I would like to put up to vote the following modified suggestion. > > > > > > 1. Wicketstuff adopts wicket style code formatting + code cleanup. This > > > covers java, xml, html, js, css files existing and future projects too. > > > > We > > > > > document this in wiki. > > > 2. The java source gets reformatted and committed. These commits will > > > > hold > > > > > no functional change only formatting. This step will be repeated to > > > time > > > > to > > > > > time (for example: once in a month near before a release) to get the > > > > source > > > > > into consistent shape. > > > 3. There will be one directory at the top level of the repo where we > > > can put IDE specific config files. Only a few files and they must be > > > applied manually if someone wants to use them. For example: I would > > > like to put > > > > up > > > > > an xml containing the adopted formatting that can be imported into > > > > Eclipse > > > > > and made a workspace default. IDEA users could put there a similar xml > > > > for > > > > > that IDE. > > > 4. Optionally we set up a checkbox xml to check for the rules. This can > > > > be > > > > > used by CI and IDE plugins to mark formatting violations as warnings. > > > > > > Doing these will be a big step forward in wicketstuff and code quality. > > > I can do 1, 2, 3 (Eclipse part) for the rest I hope other committers > > > can contribute. > > > > > > Please vote with > > > +1 if you are for it > > > -1 if you are against it, in this case please explain your reasons > > > > > > This is the first time I put up a vote but I think 3 days should be > > > > enough > > > > > for it. So vote until tuesday. > > > > > > > > > Thanks > > > Attila
