Hi,
I agree that it would be nice to have some automatism to do the
formatting. I looked at this for my former company a few years ago and
there weren't that many options available, the Maven formatter plugin
you mentioned being the only free option with rather limited options.
Jalopy is a very good tool for Source code formatting which also
integrates in all major IDEs but unfortunately it's commercial:
http://www.triemax.com/products/
I would be fine with anything as long as it is then used as a guideline.
Once we have this guideline in place (probably the default options of
the Maven plugin) we can see if we can make formatter configurations for
the IDEs available.
Regards
Florian
On 19.09.2013 16:24, Svante Schubert wrote:
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
--
Florian Hopf
Freelance Software Developer
http://blog.florian-hopf.de