In case other folk find it useful, a checkstyle setup that ignores anything that jalopy can fix. The point of this is that you never get errors simply because of a mismatch in the jalopy and checkstyle setups.

# Everything here is in the order it appears in the
# checkstyle manual http://checkstyle.sourceforge.net/config.html
# to make it easier to find the explanations.
# CHECKS FOR JAVADOC COMMENTS
# javadoc checks are broken in jalopy so will use checkstyle.
# only check public scope - being gentle to begin with
checkstyle.javadoc.scope = public
# again, be gentle
checkstyle.require.package.html = false
checkstyle.require.version = false
checkstyle.allow.no.author = false
# dont stop me documenting RuntimeExceptions!
checkstyle.javadoc.checkUnusedThrows = false

# CHECKS FOR NAMING CONVENTIONS
checkstyle.pattern.member = ^[a-z][a-zA-Z0-9]*$
checkstyle.pattern.publicmember = ^f[A-Z][a-zA-Z0-9]*$
checkstyle.pattern.const = ^[A-Z]([A-Z0-9_]*[A-Z0-9])?$
checkstyle.pattern.static = ^[a-z][a-zA-Z0-9]*$
checkstyle.pattern.parameter = ^[a-z][a-zA-Z0-9]*$
checkstyle.pattern.package = ^[a-z]+(\.[a-zA-Z_][a-zA-Z_0-9]*)*$
checkstyle.pattern.type = ^[A-Z][a-zA-Z0-9]*$
checkstyle.pattern.method = ^[a-z][a-zA-Z0-9]*$
checkstyle.pattern.localvar = ^[a-z][a-zA-Z0-9]*$
checkstyle.pattern.localfinalvar = ^[a-z][a-zA-Z0-9]*$

# CHECKS FOR HEADERS
# leave this to jalopy
checkstyle.header.file =
checkstyle.header.regexp = false
checkstyle.header.ignoreline =

# CHECKS FOR IMPORTS
# leave this to jalopy
checkstyle.ignore.imports = true

# CHECKS FOR SIZE VIOLATIONS
# still check these because jalopy can't fix every line.
checkstyle.maxlinelen = 80
checkstyle.tab.width = 4
checkstyle.ignore.importlength = false
checkstyle.ignore.maxlinelen = @version
checkstyle.maxmethodlen = 150
checkstyle.maxconstructorlen = 150
checkstyle.maxfilelen = 2000
checkstyle.maxparameters = 7

# CHECKS FOR WHITESPACE
# leave this to jalopy
checkstyle.allow.tabs = true
checkstyle.ignore.whitespace = true
# this is the variant in the checkstyle manual
checkstyle.ignore.whitespace.cast = true
# and this is what was in maven?
checkstyle.ignore.cast.whitespace = true
checkstyle.paren.pad = ignore
checkstyle.wrap.operator = ignore

# CHECKS FOR MODIFIERS
checkstyle.ignore.public.in.interface = false
checkstyle.allow.protected = false
checkstyle.allow.package = false

# CHECKS FOR BRACES
# leave this to jalopy
checkstyle.ignore.braces = true
checkstyle.block.try = ignore
checkstyle.block.catch = ignore
checkstyle.block.finally = ignore
checkstyle.lcurly.type = ignore
checkstyle.lcurly.method = ignore
checkstyle.lcurly.other = ignore
checkstyle.rcurly.type = ignore
checkstyle.rcurly.method = ignore
checkstyle.rcurly.other = ignore

# MISCELLANEOUS CHECKS
checkstyle.pattern.todo = TODO:
checkstyle.ignore.longell = false
checkstyle.illegal.instantiations =


Brian Ewins wrote:

Ara Abrahamian wrote:

Imho no need for a new entry in POM for this. I assume we use Jalopy.

Anyone else notice that the Jalopy config shipped with b7 doesnt match the Checkstyle config? (jalopy places '{' on the line after a method declaration, and checkstyle complains).

What a user should do is either use the built-in jalopy settings file
which defines a coding convention file based on Sun's convention or
defines his own file and setups maven.jalopy.style property. Now what we
should do is write an XSLT which reads this settings file and generates
a page during site:generate that shows the coding convention in readable
html format.

+1. This would be really useful.

Another useful transform would be to turn 'checkstyle' rules into their jalopy equivalent. Or alternatively, supply a checkstyle setup that ignores all the things you can fix with jalopy (which, now that I've thought of it, is how I'm going to lobotomize mine...)

-Baz

Ara.

-----Original Message-----
From: Jason van Zyl [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, November 20, 2002 10:04 AM
To: Turbine Maven Users List
Subject: User requests for POM Additions

Hi,

I've created a component in jira called "Requested POM Additions".

I would like to try and field requests for new POM additions from

users

to try and make the POM as complete and useful as possible before the
1.0 release.

The was sparked by the commons-dev request to have a standard place
describing a project's coding standard. So this might be something

that

we could add to the POM.

So, if you have an idea feel free to stick it in jira with a

description

and some form of a usecase.

--
jvz.

Jason van Zyl
[EMAIL PROTECTED]
http://tambora.zenplex.org

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.

 -- Jacques Ellul, The Technological Society


--
To unsubscribe, e-mail:   <mailto:turbine-maven-user-
[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:turbine-maven-user-
[EMAIL PROTECTED]>



--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>



--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to