[
https://issues.apache.org/jira/browse/SAMZA-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14119120#comment-14119120
]
David Chen commented on SAMZA-36:
---------------------------------
For (1), we would probably need to check in the Eclipse and IntelliJ formatter
files and then tweak the 'idea' and 'eclipse' plugins to use them for setting
up the project files.
The main challenge of (2) is that while there is a [Checkstyle plugin for
Gradle|http://www.gradle.org/docs/current/userguide/checkstyle_plugin.html],
Checkstyle style files are less common than Eclipse or IntelliJ formatter
files. I know that there currently does not exist an official Checkstyle file
for the Google Java coding style but apparently it is a [GSoC 2014
project|https://github.com/checkstyle/checkstyle/wiki/Checkstyle-GSoC-2014-Project-Ideas].
(3) might be possible:
http://blogs.operationaldynamics.com/andrew/software/java-gnome/eclipse-code-format-from-command-line
> Define and enforce coding style
> -------------------------------
>
> Key: SAMZA-36
> URL: https://issues.apache.org/jira/browse/SAMZA-36
> Project: Samza
> Issue Type: Bug
> Components: build, docs
> Affects Versions: 0.6.0
> Reporter: Chris Riccomini
>
> We should define and enforce a coding style for Samza.
> 1. Define the coding style in English on the Coding Guide page.
> 2. Enforce the coding style using whatever mechanism works best (Checkstyle,
> Scalastyle, or a custom Gradle task).
> 3. Provide appropriate formatters for Eclipse and IDEA.
> We'll have to mess around and see what works best for this. I think we can
> make ./gradlew eclipse and ./gradlew idea generate
> projects/workspaces/settings with the appropriate code formatters using
> Gradle's Eclipse and IDEA plugins:
> * http://www.gradle.org/docs/current/userguide/eclipse_plugin.html
> * http://www.gradle.org/docs/current/userguide/idea_plugin.html
> In the Eclipse case, there is a task called eclipseJdt, which can take an
> input file, when generating the JDT file
> (.settings/org.eclipse.jdt.core.prefs).
> In the IDEA case, the same pattern can be followed. I'm not sure in IntelliJ
> if the settings are in the .ipr, ,iml, or .iws file, but it can handle all of
> these.
> I suggest we put the Eclipse and IntelliJ files in a folder called
> "gradle/config".
> Regarding enforcement, a pretty simple way to do this is to create a Gradle
> task that runs the Eclipse formatter, and then does a git diff to see if
> anything changed. See this page for details:
> http://blogs.operationaldynamics.com/andrew/software/java-gnome/eclipse-code-format-from-command-line.
> {noformat}
> $ git diff --exit-code
> .. some stuff ..
> $ echo $?
> 1
> $ git checkout settings.gradle
> $ echo $?
> 0
> {noformat}
> An alternative enforcement mechanism is to use Checkstyle and Scalastyle,
> though I'm not sure Scalastyle is sufficient to enforce everything we need. I
> think the best approach is to just try them and see which one works.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
