Re: [Wicketstuff 1.5] Code formatting
2011/4/13 Emond Papegaaij emond.papega...@topicus.nl On Wednesday 13 April 2011 11:11:47 Attila Király wrote: As I see to use maven-eclipse-plugin one has to use mvn eclipse:eclipse or something like that on the command line to generate the Eclipse project files. Am I correct? In this case imho this qualifies as manual usage (if someone does not want it do not run it). So if you can provide a configuration for that making your life easier go for it. Then I will certainly do that (or at least try to). It should be possible. If not with maven-eclipse-plugin directly we could come up with a script based (ant comes to mind) solution to copy the needed files from one directory to several project directories. If you need help let me know. Attila
[Wicketstuff 1.5] Code formatting
Hi! Starting this discussion because as it turned out there is a need among the committers to establish a common code formatting in wicketstuff. [1] So maybe it is time to have a bit of brainstorming about it. How to do it? What should it cover? What do you think? Having a common code formatting would ease the cross work between the wicketstuff projects. Currently it is very inconsistent not just between modules but a lot of time inside a project too. Imho: We should simply adopt wicket's style (formatting + Save Actions) for the whole wicketstuff project. Not because I like that style of formatting that much (as every dev I also have a different opinion about The True Formatting Rule :)) but it is consistent and wicket is the upstream project so (probably) most of the wicketstuff commiters are used to it. For js, xml, html, css files we should use the same indentation style as for the java files. So in case we adopt wicket's style we should use tabs in these files too. We can add the eclipse prefs to git so it gets configured automatically. Do not know how to do it for other IDE-s. If we add this I do not think that we should reformat all projects at once. Only to do it when we touch a project or file. A complete reformat could make it harder to dig in the version history of the files. Attila [1] topic originally started here: https://github.com/wicketstuff/core/commit/2d4ed55267cfee38fcdf33b89810edc048f766f1#comments
Re: [Wicketstuff 1.5] Code formatting
Hi, I agree that we need a common formatting and same formatting rules as Wicket is a good choice. But I disagree to add specific Eclipse settings in wicketstuff, all configuration can be set by maven in pom.xml, and I suppose to put this kind of configuration in both pom.xml of wicketstuff-parent (core-1.4.x and master), I am pretty sure that it exist a maven plugin for that (maven-checkstyle ? other ?). Since I know maven, I like to think that it must be only project specific files, not specific IDEs files in repository. -- Isammoc 2011/4/7 Attila Király kiralyattila...@gmail.com Hi! Starting this discussion because as it turned out there is a need among the committers to establish a common code formatting in wicketstuff. [1] So maybe it is time to have a bit of brainstorming about it. How to do it? What should it cover? What do you think? Having a common code formatting would ease the cross work between the wicketstuff projects. Currently it is very inconsistent not just between modules but a lot of time inside a project too. Imho: We should simply adopt wicket's style (formatting + Save Actions) for the whole wicketstuff project. Not because I like that style of formatting that much (as every dev I also have a different opinion about The True Formatting Rule :)) but it is consistent and wicket is the upstream project so (probably) most of the wicketstuff commiters are used to it. For js, xml, html, css files we should use the same indentation style as for the java files. So in case we adopt wicket's style we should use tabs in these files too. We can add the eclipse prefs to git so it gets configured automatically. Do not know how to do it for other IDE-s. If we add this I do not think that we should reformat all projects at once. Only to do it when we touch a project or file. A complete reformat could make it harder to dig in the version history of the files. Attila [1] topic originally started here: https://github.com/wicketstuff/core/commit/2d4ed55267cfee38fcdf33b89810edc048f766f1#comments
Re: [Wicketstuff 1.5] Code formatting
I totally agree on this. Especially forcing the formatting in Eclipse makes the code very uniform. We use the same setup at Topicus and it works extremely well. I don't really care about the actual style itself, as long as it is readable. Wicket's formatting seems like a sane choice to me. I don't know if it is possible to let the Maven Eclipse plugin configure these settings. If so, that would be my choice. At Topicus we use svn:externals to add the same settings directory to every project. I don't know if this possible with git. Best regards, Emond Papegaaij On Thursday 07 April 2011 08:04:44 Attila Király wrote: Hi! Starting this discussion because as it turned out there is a need among the committers to establish a common code formatting in wicketstuff. [1] So maybe it is time to have a bit of brainstorming about it. How to do it? What should it cover? What do you think? Having a common code formatting would ease the cross work between the wicketstuff projects. Currently it is very inconsistent not just between modules but a lot of time inside a project too. Imho: We should simply adopt wicket's style (formatting + Save Actions) for the whole wicketstuff project. Not because I like that style of formatting that much (as every dev I also have a different opinion about The True Formatting Rule :)) but it is consistent and wicket is the upstream project so (probably) most of the wicketstuff commiters are used to it. For js, xml, html, css files we should use the same indentation style as for the java files. So in case we adopt wicket's style we should use tabs in these files too. We can add the eclipse prefs to git so it gets configured automatically. Do not know how to do it for other IDE-s. If we add this I do not think that we should reformat all projects at once. Only to do it when we touch a project or file. A complete reformat could make it harder to dig in the version history of the files. Attila [1] topic originally started here: https://github.com/wicketstuff/core/commit/2d4ed55267cfee38fcdf33b89810edc0 48f766f1#comments
Re: [Wicketstuff 1.5] Code formatting
At Topicus we use svn:externals to add the same settings directory to every project. I don't know if this possible with git. The submodule system in Git is not as easy as SVN one. It's more powerfull imho, but, here, it's an elephant for a banana.
Re: [Wicketstuff 1.5] Code formatting
Hi, I'm also +1 to format the code. I think we should define the settings and do one big formatting commit. It is easy to see that the change is formatting without functional changes and ignore the changelist when looking in history. It is much harder to look for a functional change and it is inside a change that also formats the code. About .settings/ vs. maven-eclipse-plugin: I'm +1 for .settings/. I'm a user of m2eclipse (Eclipse) plugin and this one doesn't play nice together with maven-eclipse-plugin. And I think m2eclipse is much more powerful than m-e-p. martin-g On Thu, Apr 7, 2011 at 8:04 AM, Attila Király kiralyattila...@gmail.comwrote: Hi! Starting this discussion because as it turned out there is a need among the committers to establish a common code formatting in wicketstuff. [1] So maybe it is time to have a bit of brainstorming about it. How to do it? What should it cover? What do you think? Having a common code formatting would ease the cross work between the wicketstuff projects. Currently it is very inconsistent not just between modules but a lot of time inside a project too. Imho: We should simply adopt wicket's style (formatting + Save Actions) for the whole wicketstuff project. Not because I like that style of formatting that much (as every dev I also have a different opinion about The True Formatting Rule :)) but it is consistent and wicket is the upstream project so (probably) most of the wicketstuff commiters are used to it. For js, xml, html, css files we should use the same indentation style as for the java files. So in case we adopt wicket's style we should use tabs in these files too. We can add the eclipse prefs to git so it gets configured automatically. Do not know how to do it for other IDE-s. If we add this I do not think that we should reformat all projects at once. Only to do it when we touch a project or file. A complete reformat could make it harder to dig in the version history of the files. Attila [1] topic originally started here: https://github.com/wicketstuff/core/commit/2d4ed55267cfee38fcdf33b89810edc048f766f1#comments -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com http://jweekend.com/
Re: [Wicketstuff 1.5] Code formatting
On Thu, Apr 7, 2011 at 2:04 AM, Attila Király kiralyattila...@gmail.com wrote: We can add the eclipse prefs to git so it gets configured automatically. Do not know how to do it for other IDE-s. If we add this I do not think that we should reformat all projects at once. Only to do it when we touch a project or file. A complete reformat could make it harder to dig in the version history of the files. Just use checkstyle: http://checkstyle.sourceforge.net/
Re: [Wicketstuff 1.5] Code formatting
On Thu, Apr 7, 2011 at 6:47 AM, James Carman ja...@carmanconsulting.com wrote: On Thu, Apr 7, 2011 at 2:04 AM, Attila Király kiralyattila...@gmail.com wrote: We can add the eclipse prefs to git so it gets configured automatically. Do not know how to do it for other IDE-s. If we add this I do not think that we should reformat all projects at once. Only to do it when we touch a project or file. A complete reformat could make it harder to dig in the version history of the files. Just use checkstyle: http://checkstyle.sourceforge.net/ Sorry, hit send too early (it's too early for me apparently). Trying to maintain all of these settings for different IDEs and checking them into SVN isn't a good idea. Checkstyle can help you flag code that looks funny using the CI server (or when they build it locally)
Re: [Wicketstuff 1.5] Code formatting
(Also an answer to Hans Lesmeister) Afaik there is no checkstyle plugin that can do the same as eclipse formatter + save actions: format and clean up code upon save. Checkstyle will only test that the rules are met or not. It is not very convenient (also not possible to reformat whole projects with one click). It seems CXF could manage it somehow but it does not look pretty: http://cxf.apache.org/connecting-maven-eclipse-checkstyle-and-pmd.html 2011/4/7 James Carman ja...@carmanconsulting.com On Thu, Apr 7, 2011 at 6:47 AM, James Carman ja...@carmanconsulting.com wrote: On Thu, Apr 7, 2011 at 2:04 AM, Attila Király kiralyattila...@gmail.com wrote: We can add the eclipse prefs to git so it gets configured automatically. Do not know how to do it for other IDE-s. If we add this I do not think that we should reformat all projects at once. Only to do it when we touch a project or file. A complete reformat could make it harder to dig in the version history of the files. Just use checkstyle: http://checkstyle.sourceforge.net/ Sorry, hit send too early (it's too early for me apparently). Trying to maintain all of these settings for different IDEs and checking them into SVN isn't a good idea. Checkstyle can help you flag code that looks funny using the CI server (or when they build it locally)
Re: [Wicketstuff 1.5] Code formatting
On Thu, Apr 7, 2011 at 7:48 AM, Attila Király kiralyattila...@gmail.com wrote: (Also an answer to Hans Lesmeister) Afaik there is no checkstyle plugin that can do the same as eclipse formatter + save actions: format and clean up code upon save. Checkstyle will only test that the rules are met or not. It is not very convenient (also not possible to reformat whole projects with one click). Again, we don't all use Eclipse. The Checkstyle plugin is convenient because it works in any environment (IDE or not).
Re: [Wicketstuff 1.5] Code formatting
e.g. I could not configure that IDEA respects blanks at the end of javadoc lines javadoc formatting in general is complicated to keep in sync with wicket's guideline (e.g. alignment of description for @param) /*[blank] Am 07.04.2011 um 13:31 schrieb Attila Király: What does IDEA not like about wicket's style? Btw. IDEA can also format files automatically on save? 2011/4/7 Peter Ertl pe...@gmx.org Tortured by IDEA's resistance to adjust formatting to wicket's guideline I would greatly appreciate that... Am 07.04.2011 um 12:55 schrieb Hans Lesmeister 2: you could provide one checkstyle ruleset so you are IDE-independant which I think is very important. For every IDE, for Maven and for Ant there are plenty of plugins that can be used. - -- Regards, Hans http://cantaa.de -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicketstuff-1-5-Code-formatting-tp3432552p3433008.html Sent from the Forum for Wicket Core developers mailing list archive at Nabble.com.
Re: [Wicketstuff 1.5] Code formatting
On Thu, Apr 7, 2011 at 1:54 PM, James Carman ja...@carmanconsulting.comwrote: On Thu, Apr 7, 2011 at 7:48 AM, Attila Király kiralyattila...@gmail.com wrote: (Also an answer to Hans Lesmeister) Afaik there is no checkstyle plugin that can do the same as eclipse formatter + save actions: format and clean up code upon save. Checkstyle will only test that the rules are met or not. It is not very convenient (also not possible to reformat whole projects with one click). Again, we don't all use Eclipse. The Checkstyle plugin is convenient because it works in any environment (IDE or not). Does that mean that when I save a file or format it explicitly in my IDE the checkstyle plugin will intercept the action and apply its settings ? Using checkstyle in Maven is stupid for this kind of projects - OSS development in my spare time. I will be very unhappy to code something in 30mins and then to spend another 30mins or more trying to apply *manually*the formatting style in my IDE just to satisfy the build tool. -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com http://jweekend.com/
Re: [Wicketstuff 1.5] Code formatting
IMHO Formatting should be done on commit. - -- Regards, Hans http://cantaa.de -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicketstuff-1-5-Code-formatting-tp3432552p3433490.html Sent from the Forum for Wicket Core developers mailing list archive at Nabble.com.
Re: [Wicketstuff 1.5] Code formatting
On Thu, Apr 7, 2011 at 3:51 PM, Hans Lesmeister 2 hans.lesmeis...@lessy-software.de wrote: IMHO Formatting should be done on commit. I guess you don't follow your colleagues work using email notifications. - -- Regards, Hans http://cantaa.de -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicketstuff-1-5-Code-formatting-tp3432552p3433490.html Sent from the Forum for Wicket Core developers mailing list archive at Nabble.com. -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com http://jweekend.com/
Re: [Wicketstuff 1.5] Code formatting
I agree - commit-hook-based formatting would be awful, for several reasons: 1 - formatting CAN break code (I know it doesn't usually, but can), but besides that, if I commit, what I worked on should be transmitted to the server and stored in the history - not some mutated version 2 - the statement that everyone can format how he or she likes is FALSE. If I check-in my 16-char tabulation file and you check in your 2-tab-per-tab-tabulation file, and both are transformed to three-spaces-two-commas-and-a-pipe formatting (yes, I'm making that stuff up) when I check out my file, I get the re-formatted version, and so does two-tab guy. So NEITHER of us is working with the same format we like / checked in. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org* On Thu, Apr 7, 2011 at 2:16 PM, Martin Grigorov mgrigo...@apache.orgwrote: Are you sure ? I have never used something like this but it sounds bad. I commit something and then when I open the logs I see something different (my change + some formatting). This way the history is totally messed up. On Thu, Apr 7, 2011 at 6:19 PM, Peter Ertl pe...@gmx.org wrote: +1 on commit-hook-based code formatting Am 07.04.2011 um 18:06 schrieb Hans Lesmeister 2: Martin Grigorov-4 wrote: On Thu, Apr 7, 2011 at 3:51 PM, Hans Lesmeister 2 hans.lesmeis...@lessy-software.de wrote: IMHO Formatting should be done on commit. I guess you don't follow your colleagues work using email notifications. I am not sure if I know what you mean by that. With on commit I meant on the server, in this case the Git-Server. That way everybody can format the way he or she likes. - -- Regards, Hans http://cantaa.de -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicketstuff-1-5-Code-formatting-tp3432552p3433858.html Sent from the Forum for Wicket Core developers mailing list archive at Nabble.com. -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com http://jweekend.com/
Re: [Wicketstuff 1.5] Code formatting
jer...@wickettraining.com wrote: 1 - formatting CAN break code (I know it doesn't usually, but can), We have done post-commit-hook-formatting on a big project and luckily never had a code break. But theoretically you're absolutely right. 2 - the statement that everyone can format how he or she likes is FALSE. If I check-in my 16-char tabulation file and you check in your 2-tab-per-tab-tabulation file, and both are transformed to three-spaces-two-commas-and-a-pipe formatting (yes, I'm making that stuff up) when I check out my file, I get the re-formatted version, and so does two-tab guy. So NEITHER of us is working with the same format we like / checked in. I think we have a misunderstanding here. If I checkin my code then it is reformatted by the commit-hook and I get back the formatted code in my workspace immediately (like with expanding those CVS variables you can embed in your code). This way the history only shows the changes I really made and there is no mess up of the history because of changes caused by formatting. Anyhow, with commit-hook-formatting we made very good experience. Developers really can format the way they like, or at least do not need to bother at all with plugins, settings, etc. As soon as they checkin, their code is formatted on the server *and* in their workspace. when I check out my file, I get the re-formatted version, and so does two-tab guy. So NEITHER of us is working with the same format we like No, you get the re-formatted version when you check in. You don't care about formatting until checkin. No need to make sure the formatting is conform the rules. commit-hook takes care about that. That's the only difference. - -- Regards, Hans http://cantaa.de -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicketstuff-1-5-Code-formatting-tp3432552p3435345.html Sent from the Forum for Wicket Core developers mailing list archive at Nabble.com.
