pig-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benjamin Francisoud (JIRA)" <j...@apache.org>
Subject [jira] Updated: (PIG-128) Incorporate CheckStyle into Pig build.xml (experimental)
Date Fri, 29 Feb 2008 14:14:54 GMT

     [ https://issues.apache.org/jira/browse/PIG-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Benjamin Francisoud updated PIG-128:

    Attachment: PIG-128-v02.patch

I don't know why but TortoiseMerge couldn't apply the pig_checkstyle1.patch, it was complaining
about an unknown line ending at line 10 ?!

I applied the modification manually (luckily the patch wasn't big)

The patch is good in my opinion :)

Some remarks, I don't think we should create an other build-lib folder to hold checkstyle
We should put it under lib for the moment. Eventually create sub folders in lib or (even better
in my opinion) use ivy to manage such dependencies...

I changed the name of the checktyle config from pig_checks.xml to checktyle.xml (I think the
name state more clearly what is in this file without opening it)

I improved build.xml:
* made the checkstyle warning display on screen or in a file configurable through the checkstyle.useFile
* replaced some tabs with whitespaces (but I'm becoming picky here ;) )
* added test / ... *.java to the list of files to verify

The checkstyle jar was missing, I will add it as an attachment in this bug.

> Incorporate CheckStyle into Pig build.xml  (experimental)
> ---------------------------------------------------------
>                 Key: PIG-128
>                 URL: https://issues.apache.org/jira/browse/PIG-128
>             Project: Pig
>          Issue Type: Improvement
>    Affects Versions: 0.1.0
>            Reporter: Pi Song
>             Fix For: 0.1.0
>         Attachments: PIG-128-v02.patch, pig_checkstyle1.patch
> As discussed in the mailing list, now I have included CheckStyle as a part of the build
process. Some might agree and some might not agree. Please note that initially *this is only
for experimental purpose*. 
> In my opinion, this is a systematic way to control coding style as you expect more and
more people coming to help, you will need a good system to support.
> *Proposal*
> +Stage1+
> - Checkstyle will run as a part of build process. The output file will be created at
build/checkstyle/checkstyle-report.txt. This only took a few more seconds in my slow development
> - At the moment sun's guideline is used with special exceptions Indentation=4 and neglecting
package.html requirement.
> - Failures on Checkstyle will not cause the build to be broken at this stage as this
will only provide guideline for developers and for committers to make decisions whether the
patch is ready to be committed. Basically new patches should not introduce more violations.
> - From time to time, we should spend some time cleaning up code to reduce the number
of violations. Before, people just did clean-up and check-in believing the code would be cleaner.
Now you will have a good indicator to showcase your achievement.
> +Stage2+ (don't know when yet)
> - It's interesting that some checks in Checkstyle can help us eliminate unforseen bugs
such as DoubleCheckingLock, EqualsHashCode, MagicNumber, or StringLiteralEquality. These checks
should be enforced as errors and break the build. The set of such hard checks needs us all
to decide. (see http://checkstyle.sourceforge.net/config_coding.html)
> From my test, currently we have around 10000 violations. 
> Awaiting for suggestions!!!

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message