@yinlinchen, I realize that your IDE reformatted the code and that the reformatted versions also pass the checkstyle checks. However, including unrelated format updates in pull-requests makes it very difficult to inspect git history for functional changes. Please remove the format updates as a new commit on the branch.
@ksclarke, do you have suggestions on how to tame Eclipse?

@awoods, I think the right way is to make the formatted correct. The
Eclipse IDE correctly reformatted the source code and made it right.

Take this PR as an example, the import order in RdfSerializationUtils.java
and CacheEntryFactory.java were wrong and the IDE correct the import order.

As you see the diff, github use dark red/dark green to show the indent, it
is not that difficult for you or other committers to see the formatted
changes.

Unless the source code formatted by intellij and Eclipse (or other IDE) are
different, we should make the source code formatted correct and fix the
wrong format. isn't it?

On Tue, Feb 10, 2015 at 8:32 PM, Andrew Woods notifications@github.com
wrote:

@yinlinchen https://github.com/yinlinchen, I realize that your IDE
reformatted the code and that the reformatted versions also pass the
checkstyle checks. However, including unrelated format updates in
pull-requests makes it very difficult to inspect git history for functional
changes. Please remove the format updates as a new commit on the branch.
@ksclarke https://github.com/ksclarke, do you have suggestions on how
to tame Eclipse?

—
Reply to this email directly or view it on GitHub
#709 (comment).

Regards,
Yinlin

The issue is with mixing functional and non-functional (formatting) changes in a single commit.

If you want to reformat classes, you are welcome to. But if you do so, create a separate JIRA ticket for reformatting classes, and make sure that you do not include any functional updates in those commits and make sure that your commit comment clearly states that the updates are non-functional.

@yinlinchen I have had this conversation with @awoods before, and I think others also have. There's no point in remonstrating with him.

Ok, I agree with you.

In Eclipse, there is a function which can reformat source code whole
project/package. So I can very easily to create a JIRA and submit PR about
non-functional (formatting) changes in a couple of minutes.

However, the modified files in this PR will be a lot, do you or any others
have time to review this PR?

For now, what I can do is to disable the Eclipse save action. Which is
fine, just increasing my time to work on the tickets.

On Tue, Feb 10, 2015 at 11:34 PM, Andrew Woods notifications@github.com
wrote:

The issue is with mixing functional and non-functional (formatting)
changes in a single commit.

If you want to reformat classes, you are welcome to. But if you do so,
create a separate JIRA ticket for reformatting classes, and make sure that
you do not include any functional updates in those commits and make sure
that your commit comment clearly states that the updates are non-functional.

—
Reply to this email directly or view it on GitHub
#709 (comment).

@yinlinchen, I agree that reformatting the codebase is likely a waste of everyone's time... because the next person that comes along will want to do it all over again (you are not the first and will not be the last).
A more constructive path is to update the checkstyle rules to be more strict, if you believe there is a specific formatting pattern that should be further enforced.
see: https://github.com/fcrepo4/fcrepo-build-tools/tree/master/src/main/resources/fcrepo-checkstyle

Checkstyle import directives are listed here:
http://checkstyle.sourceforge.net/config_imports.html

Resolved with: 96993ce