Hi, I have added the plugin behind the rat plugin under <build><plugins>, it was triggered during my test by just building the project. There had been a lot of changes and the line indent formatting was exactly as the IDE Eclipse is using it. I agree I would prefer to use a source formatting plugin that could be used by Netbeans as well, as the Netbeans IDE has a different source code formatting than Eclipse.
My 2cents: I do not care about formatting, I would love to have this kind of "changes noise" out of my way when merging branches. Any other suggestions to solve the problem in a different way, for instance via a different Maven Plugin? Kind regards, Svante Am 14.09.2013 11:00, schrieb Oliver Rau: > Hi guys, > > Just my two cents to this topic. > > I agree with Ian on this one. We should agree on a format first (e.g. use > spaces over tabs with a width of 4, plus e.g. a statement like "besides > that we follow the java guidelines"). This format can then be applied in > any way that fits for the developer (editor or build). In addition we could > provide formatters for eclipse as well as netbeans. If code checkins don't > meet that requirement the community can reject them unless there are good > reasons. Having that kind of tooling with the build, should be for > convenience and manually triggered, forcing a styling during build or > checkin might lead to unwanted results as it might do things that a > developer doesn't foresee. > > As a rule of thumb, whenever I need to work on a unformatted file, I format > it and check it in with the remark "just reformatting" and then I do the > actual work with a new checkin. > > > Kind Regards, > > > Oliver > > > On Sat, Sep 14, 2013 at 5:17 AM, Ian C <[email protected]> wrote: > >> Hi Svante, >> >> >> On Fri, Sep 13, 2013 at 7:44 PM, Svante Schubert >> <[email protected]>wrote: >> >>> When comparing the current sources of the ODF Toolkit with the sources >>> with my branch by a text compare, I got a lot of "change noise", >>> triggered by different indentation methods being used by Netbeans and >>> Eclipse. >>> Annoyed by this a long time, I gave it a try and tested successfully a >>> Maven Tool that allowed the Source Normalization before building the >>> sources. >>> >>> >>> >> http://maven-java-formatter-plugin.googlecode.com/svn/site/0.4/examples.html >>> You may test it by adding it to your build plugins (behind the RAT) in >>> the pom.xml: >>> <plugin> >>> <groupId>com.googlecode.maven-java-formatter-plugin</groupId> >>> <artifactId>maven-java-formatter-plugin</artifactId> >>> <version>0.4</version> >>> <configuration> >>> <lineEnding>LF</lineEnding> >>> </configuration> >>> <executions> >>> <execution> >>> <goals> >>> <goal>format</goal> >>> </goals> >>> </execution> >>> </executions> >>> </plugin> >>> >>> After using this in both frameworks, I could far easier identify the >>> differences. >>> >>> My plan is to add this to my branch and the project and do a commit >>> without any further changes, end of next week. >>> >>> Any comments are welcome. >>> >> I tried the plugin and eventually discovered that in order to run it I >> needed to enter the full goal... >> mvn >> >> com.googlecode.maven-java-formatter-plugin:maven-java-formatter-plugin:format >> >> Which was not immediately obvious to me. >> >> But looking at the changes via my SVN client I see just about everything >> has changed. >> >> Things like - from the GraphicsDocument class >> static final Resource EMPTY_GRAPHICS_DOCUMENT_RESOURCE = new >> Resource(EMPTY_GRAPHICS_DOCUMENT_PATH); >> goes to >> static final Resource EMPTY_GRAPHICS_DOCUMENT_RESOURCE = new Resource( >> EMPTY_GRAPHICS_DOCUMENT_PATH); >> >> Whilst I am not too fussed about it,is this what we want? Looks like it >> must be applying a line length wrapping? >> >> Do we need to figure out an agreed format? Are there some canned formats to >> choose from? >> >> Did you see as many changes? Checking in the reformat will affect almost >> all files (3 skipped)? >> >> >> >>> Kind regards, >>> Svante >>> >> >> >> -- >> Cheers, >> >> Ian C >>
