Mark, I am always keen to see Checkstyle get used - but some may say I am biased. :-)
Yes, the configuration mechanism did change between Checkstyle 2.3 and 2.4. The changes you outlined are correct. The most likely cause of the errors in the Chainsaw source are due to the extra checks added in 2.4. Without running 2.4 I cannot confirm this. When you commit your changes I will fix the errors. Adopting Checkstyle to an existing code base is a thing that should be done with much care. As you have no doubt noticed, Checkstyle is very unrelenting in reporting errors (I have seen 100,000 errors on a project). It is important to first get agreement that you want to follow a coding standard. Assuming this is the case, and your comments suggest it is the case, then a consensus needs to be reached on what it is. Other Jakarta projects are going through this process. See http://www.mail-archive.com/struts-dev@jakarta.apache.org/thrd4.html#12374. Personally I would recommend the Sun coding standards as a starting position and just put the case for deviations. I would also suggest that it may be appropriate for Ceki to provide some "guidance". Assuming agreement is gained for the coding standard, you are then in a position to start to enforce it with Checkstyle. However I would recommend applying the Checks a bit at a time, or on a package at a time. This is to keep down the number of errors. I am more than happy to help with the configuration of Checkstyle. I should point out that a beta has been released of Checkstyle 3.0. The configuration has been re-worked and is now XML based. The main advantage of version 3.0 is that it now has a framework for plugging in external Checks. So if the Log4J project comes up with some unique coding standards, then a Check can be easily written to enforce it. Regards, Oliver > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Monday, 3 February 2003 18:23 > To: Log4J Developers List > Subject: RE: checkstyle.properties? > > > I realized that the checkstyle.properties was for the ant task, not the > checkstyle settings. correct > BUT, the 2.4 version of checkstyle has a completely different > ant task, and > does need a properties file. :-) I converted the old ant task to the new > one: > > <target name="checkstyle" depends="init"> > <taskdef resource="checkstyletask.properties" > classpath="${checkstyle.jar}"/> > > <!-- by default checkstyle supports the Sun coding standard. --> > <checkstyle properties="checkstyle.properties"> > <fileset dir="src/java/org/apache/log4j/chainsaw" > includes="**/*.java"/> > <fileset dir="src/java/org/apache/log4j/plugins" > includes="**/*.java"/> > </checkstyle> > </target> > > and specified the following properties: > > checkstyle.lcurly.method=nlow > checkstyle.lcurly.type=nlow > checkstyle.lcurly.other=nlow > checkstyle.maxmethodlen=500 > checkstyle.maxconstructorlen=500 > > I know my code does not conform to the strict settings, but now even the > chainsaw code gets checkstyle errors. > > Oliver? > > Maybe we should spend some time figuring out the set of > checkstyle setting > we want to adopt. I do like the idea of using it. > > -Mark > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > > Sent: Sunday, February 02, 2003 11:05 PM > > To: Log4J Developers List > > Subject: checkstyle.properties? > > > > I decided to take the plunge and get my code (filters, > plugins) to conform > > to the checkstyle settings, only to find that the > > checkstyle.properties file > > does not appear to be checked into the log4j cvs. > > > > Oliver, Ceki, what properties file do you use for this? > > > > thanks, > > -Mark --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
