incubator-odf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Rau <ol...@apache.org>
Subject Re: Source Normalization
Date Sat, 14 Sep 2013 09:00:39 GMT
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 <ian@amham.net> wrote:

> Hi Svante,
>
>
> On Fri, Sep 13, 2013 at 7:44 PM, Svante Schubert
> <svante.schubert@gmail.com>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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message