You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@tuscany.apache.org by jm...@apache.org on 2006/06/10 07:38:22 UTC
svn commit: r413251 - in /incubator/tuscany/sandbox/jboynes/sca:
buildtools/src/main/resources/tuscany-checkstyle.xml tuscany-checkstyle.xml
Author: jmarino
Date: Fri Jun 9 22:38:21 2006
New Revision: 413251
URL: http://svn.apache.org/viewvc?rev=413251&view=rev
Log:
update checkstyle files; they are in the wrong place for now and need to be moved
Added:
incubator/tuscany/sandbox/jboynes/sca/tuscany-checkstyle.xml (with props)
Modified:
incubator/tuscany/sandbox/jboynes/sca/buildtools/src/main/resources/tuscany-checkstyle.xml
Modified: incubator/tuscany/sandbox/jboynes/sca/buildtools/src/main/resources/tuscany-checkstyle.xml
URL: http://svn.apache.org/viewvc/incubator/tuscany/sandbox/jboynes/sca/buildtools/src/main/resources/tuscany-checkstyle.xml?rev=413251&r1=413250&r2=413251&view=diff
==============================================================================
--- incubator/tuscany/sandbox/jboynes/sca/buildtools/src/main/resources/tuscany-checkstyle.xml (original)
+++ incubator/tuscany/sandbox/jboynes/sca/buildtools/src/main/resources/tuscany-checkstyle.xml Fri Jun 9 22:38:21 2006
@@ -59,12 +59,12 @@
<!-- Checks for Naming Conventions. -->
<!-- See http://checkstyle.sf.net/config_naming.html -->
- <module name="AbstractClassName">
+ <!--<module name="AbstractClassName">
<property name="format"
- value="^Abstract.*$|^.*Factory$|^.*Bus$|^.*ConfigurationRepository$|^.*Base$|^Exception$|^.*Builder$"/>
- </module>
+ value="^Abstract.*$|^.*Factory$|^.*Extension$|^.*Exception$|^.*Bus$|^.*ConfigurationRepository$|^.*Base$|^Exception$|^.*Builder$"/>
+ </module>-->
<module name="ConstantName"/>
- <module name="LocalFinalVariableName"/>
+ <!--<module name="LocalFinalVariableName"/>-->
<module name="LocalVariableName"/>
<module name="MemberName"/>
<module name="MethodName"/>
@@ -109,7 +109,7 @@
</module>
<module name="FileLength"/>
<module name="LineLength">
- <property name="max" value="115"/>
+ <property name="max" value="120"/>
</module>
<module name="MethodLength">
<property name="max" value="150"/>
@@ -137,7 +137,7 @@
</module>
<module name="WhitespaceAround">
<property name="tokens"
- value="ASSIGN, BAND, BAND_ASSIGN, BOR, BOR_ASSIGN, BSR, BSR_ASSIGN, BXOR, BXOR_ASSIGN, COLON, DIV, DIV_ASSIGN, EQUAL, GE, GT, LAND, LCURLY, LE, LITERAL_ASSERT, LITERAL_CATCH, LITERAL_DO, LITERAL_ELSE, LITERAL_FINALLY, LITERAL_FOR, LITERAL_IF, LITERAL_RETURN, LITERAL_SYNCHRONIZED, LITERAL_TRY, LITERAL_WHILE, LOR, LT, MINUS, MINUS_ASSIGN, MOD, MOD_ASSIGN, NOT_EQUAL, PLUS, PLUS_ASSIGN, QUESTION, RCURLY, SL, SLIST, SL_ASSIGN, SR, SR_ASSIGN, STAR, STAR_ASSIGN,TYPE_EXTENSION_AND"/>
+ value="ASSIGN, BAND, BAND_ASSIGN, BOR, BOR_ASSIGN, BSR, BSR_ASSIGN, BXOR, BXOR_ASSIGN, COLON, DIV, DIV_ASSIGN, EQUAL, GE, GT, LAND, LCURLY, LE, LITERAL_CATCH, LITERAL_DO, LITERAL_ELSE, LITERAL_FINALLY, LITERAL_FOR, LITERAL_IF, LITERAL_RETURN, LITERAL_SYNCHRONIZED, LITERAL_TRY, LITERAL_WHILE, LOR, LT, MINUS, MINUS_ASSIGN, MOD, MOD_ASSIGN, NOT_EQUAL, PLUS, PLUS_ASSIGN, QUESTION, SL, SLIST, SL_ASSIGN, SR, SR_ASSIGN, STAR, STAR_ASSIGN,TYPE_EXTENSION_AND"/>
</module>
@@ -169,11 +169,11 @@
<module name="EmptyStatement"/>
<module name="EqualsHashCode"/>
<!--<module name="FinalLocalVariable"/>-->
- <module name="HiddenField">
+ <!--<module name="HiddenField">
<property name="ignoreConstructorParameter" value="true"/>
<property name="ignoreSetter" value="true"/>
<property name="ignoreAbstractMethods" value="true"/>
- </module>
+ </module>-->
<module name="IllegalInstantiation"/>
<!--<module name="IllegalToken"/>-->
<!--<module name="IllegalTokenText"/>-->
@@ -199,9 +199,9 @@
<!--<module name="RedundantThrows"/>-->
<module name="PackageDeclaration"/>
<module name="JUnitTestCase"/>
- <module name="ReturnCount">
+ <!--<module name="ReturnCount">
<property name="max" value="6"/>
- </module>
+ </module>-->
<module name="IllegalType">
<property name="format" value="^xxx$"/>
@@ -275,9 +275,9 @@
</module>
<!--<module name="UncommentedMain"/>-->
- <module name="TrailingComment"/>
+ <!-- <module name="TrailingComment"/>-->
<module name="Indentation">
- <property name="caseIndent" value="0"/>
+ <property name="caseIndent" value="4"/>
</module>
<!--<module name="RequiredRegexp">-->
</module>
Added: incubator/tuscany/sandbox/jboynes/sca/tuscany-checkstyle.xml
URL: http://svn.apache.org/viewvc/incubator/tuscany/sandbox/jboynes/sca/tuscany-checkstyle.xml?rev=413251&view=auto
==============================================================================
--- incubator/tuscany/sandbox/jboynes/sca/tuscany-checkstyle.xml (added)
+++ incubator/tuscany/sandbox/jboynes/sca/tuscany-checkstyle.xml Fri Jun 9 22:38:21 2006
@@ -0,0 +1,285 @@
+<?xml version="1.0"?>
+<!--
+ Copyright (c) 2005 The Apache Software Foundation or its licensors, as applicable.
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+ -->
+<!DOCTYPE module PUBLIC
+ "-//Puppy Crawl//DTD Check Configuration 1.2//EN"
+ "http://www.puppycrawl.com/dtds/configuration_1_2.dtd">
+
+<!--
+Checks to make sure the code meets the Tuscany coding guidelines
+http://java.sun.com/docs/codeconv/index.html
+
+It also enforces aa bunch of other "BestPractices like method
+lengths, if/try depths, etc...
+
+-->
+
+<module name="Checker">
+ <property name="severity"
+ value="${checkstyle.severity}"
+ default="warning"/>
+
+ <!-- Checks whether files end with a new line. -->
+ <!-- See http://checkstyle.sf.net/config_misc.html#NewlineAtEndOfFile -->
+ <!--
+ <module name="NewlineAtEndOfFile"/>
+ -->
+
+ <!-- Checks that property files contain the same keys. -->
+ <!-- See http://checkstyle.sf.net/config_misc.html#Translation -->
+ <module name="Translation"/>
+
+ <!--<module name="StrictDuplicateCode"/>-->
+
+ <module name="TreeWalker">
+
+ <!-- Checks for Javadoc comments. -->
+ <!-- See http://checkstyle.sf.net/config_javadoc.html -->
+ <!--
+ <module name="PackageHtml"/>
+ <module name="JavadocMethod"/>
+ <module name="JavadocType"/>
+ <module name="JavadocVariable"/>
+ <module name="JavadocStyle"/>
+ -->
+
+
+ <!-- Checks for Naming Conventions. -->
+ <!-- See http://checkstyle.sf.net/config_naming.html -->
+ <!--<module name="AbstractClassName">
+ <property name="format"
+ value="^Abstract.*$|^.*Factory$|^.*Extension$|^.*Exception$|^.*Bus$|^.*ConfigurationRepository$|^.*Base$|^Exception$|^.*Builder$"/>
+ </module>-->
+ <module name="ConstantName"/>
+ <!--<module name="LocalFinalVariableName"/>-->
+ <module name="LocalVariableName"/>
+ <module name="MemberName"/>
+ <module name="MethodName"/>
+ <module name="PackageName"/>
+ <module name="ParameterName"/>
+ <module name="StaticVariableName"/>
+ <module name="TypeName"/>
+
+ <!-- Header checks -->
+ <!-- <module name="Header"/> -->
+ <!-- <module name="RegexpHeader"/> -->
+
+
+ <!-- Checks for imports -->
+ <!-- See http://checkstyle.sf.net/config_import.html -->
+ <module name="AvoidStarImport">
+ <property name="excludes"
+ value="java.io,java.util,java.net,java.nio,java.nio.channels,java.lang.reflect,org.w3c.dom,org.xml.sax,java.awt,javax.swing,junit.framework"/>
+ </module>
+ <module name="IllegalImport"/>
+ <!-- defaults to sun.* packages -->
+ <module name="RedundantImport"/>
+ <module name="UnusedImports"/>
+ <module name="ImportOrder">
+ <property name="groups" value="java,javax,org.w3c,org.xml,w3c"/>
+ <property name="ordered" value="true"/>
+ </module>
+ <!--
+ <module name="ImportControl">
+ <property name="file" value="etc/import-control.xml"/>
+ </module>
+ -->
+
+
+ <!-- Checks for Size Violations. -->
+ <!-- See http://checkstyle.sf.net/config_sizes.html -->
+ <module name="AnonInnerLength">
+ <property name="max" value="40"/>
+ </module>
+ <module name="ExecutableStatementCount">
+ <property name="max" value="50"/>
+ </module>
+ <module name="FileLength"/>
+ <module name="LineLength">
+ <property name="max" value="120"/>
+ </module>
+ <module name="MethodLength">
+ <property name="max" value="150"/>
+ <property name="countEmpty" value="false"/>
+ </module>
+ <module name="ParameterNumber">
+ <property name="max" value="7"/>
+ </module>
+
+ <!-- Checks for whitespace -->
+ <!-- See http://checkstyle.sf.net/config_whitespace.html -->
+ <module name="EmptyForIteratorPad"/>
+ <module name="EmptyForInitializerPad"/>
+ <module name="MethodParamPad"/>
+ <module name="NoWhitespaceAfter">
+ <property name="tokens" value="ARRAY_INIT,BNOT,DEC,DOT,INC,LNOT,UNARY_MINUS,UNARY_PLUS"/>
+ </module>
+ <module name="NoWhitespaceBefore"/>
+ <module name="OperatorWrap"/>
+ <module name="ParenPad"/>
+ <module name="TypecastParenPad"/>
+ <module name="TabCharacter"/>
+ <module name="WhitespaceAfter">
+ <property name="tokens" value="COMMA, SEMI"/>
+ </module>
+ <module name="WhitespaceAround">
+ <property name="tokens"
+ value="ASSIGN, BAND, BAND_ASSIGN, BOR, BOR_ASSIGN, BSR, BSR_ASSIGN, BXOR, BXOR_ASSIGN, COLON, DIV, DIV_ASSIGN, EQUAL, GE, GT, LAND, LCURLY, LE, LITERAL_CATCH, LITERAL_DO, LITERAL_ELSE, LITERAL_FINALLY, LITERAL_FOR, LITERAL_IF, LITERAL_RETURN, LITERAL_SYNCHRONIZED, LITERAL_TRY, LITERAL_WHILE, LOR, LT, MINUS, MINUS_ASSIGN, MOD, MOD_ASSIGN, NOT_EQUAL, PLUS, PLUS_ASSIGN, QUESTION, SL, SLIST, SL_ASSIGN, SR, SR_ASSIGN, STAR, STAR_ASSIGN,TYPE_EXTENSION_AND"/>
+ </module>
+
+
+ <!-- Modifier Checks -->
+ <!-- See http://checkstyle.sf.net/config_modifiers.html -->
+ <module name="ModifierOrder"/>
+ <module name="RedundantModifier"/>
+
+
+ <!-- Checks for blocks. You know, those {}'s -->
+ <!-- See http://checkstyle.sf.net/config_blocks.html -->
+ <module name="AvoidNestedBlocks">
+ <property name="allowInSwitchCase" value="true"/>
+ </module>
+ <module name="EmptyBlock">
+ <property name="option" value="text"/>
+ </module>
+ <module name="LeftCurly"/>
+ <module name="NeedBraces"/>
+ <module name="RightCurly"/>
+
+
+ <!-- Checks for common coding problems -->
+ <!-- See http://checkstyle.sf.net/config_coding.html -->
+ <!--<module name="ArrayTrailingComma"/>-->
+ <!--<module name="AvoidInlineConditionals"/>-->
+ <module name="CovariantEquals"/>
+ <module name="DoubleCheckedLocking"/>
+ <module name="EmptyStatement"/>
+ <module name="EqualsHashCode"/>
+ <!--<module name="FinalLocalVariable"/>-->
+ <!--<module name="HiddenField">
+ <property name="ignoreConstructorParameter" value="true"/>
+ <property name="ignoreSetter" value="true"/>
+ <property name="ignoreAbstractMethods" value="true"/>
+ </module>-->
+ <module name="IllegalInstantiation"/>
+ <!--<module name="IllegalToken"/>-->
+ <!--<module name="IllegalTokenText"/>-->
+ <!--<module name="InnerAssignment"/>-->
+ <!--<module name="MagicNumber"/>-->
+ <module name="MissingSwitchDefault"/>
+ <module name="ModifiedControlVariable"/>
+ <module name="SimplifyBooleanExpression"/>
+ <module name="SimplifyBooleanReturn"/>
+ <module name="StringLiteralEquality"/>
+ <module name="NestedIfDepth">
+ <property name="max" value="3"/>
+ </module>
+ <module name="NestedTryDepth">
+ <property name="max" value="3"/>
+ </module>
+ <module name="SuperClone"/>
+ <module name="SuperFinalize"/>
+ <!--<module name="IllegalCatch"/>-->
+ <module name="IllegalThrows">
+ <property name="illegalClassNames" value="java.lang.Error,java.lang.RuntimeException"/>
+ </module>
+ <!--<module name="RedundantThrows"/>-->
+ <module name="PackageDeclaration"/>
+ <module name="JUnitTestCase"/>
+ <!--<module name="ReturnCount">
+ <property name="max" value="6"/>
+ </module>-->
+
+ <module name="IllegalType">
+ <property name="format" value="^xxx$"/>
+ </module>
+ <module name="DeclarationOrder"/>
+ <!--<module name="ParameterAssignment"/>-->
+ <module name="ExplicitInitialization"/>
+ <module name="DefaultComesLast"/>
+ <!--<module name="MissingCtor"/>-->
+ <module name="FallThrough"/>
+ <!--<module name="MultipleStringLiterals"/>-->
+ <module name="MultipleVariableDeclarations"/>
+ <!--<module name="RequireThis"/>-->
+ <module name="UnnecessaryParentheses"/>
+
+
+ <!-- Checks for class design -->
+ <!-- See http://checkstyle.sf.net/config_design.html -->
+ <!--<module name="DesignForExtension"/>-->
+ <module name="FinalClass"/>
+ <module name="HideUtilityClassConstructor"/>
+ <module name="InterfaceIsType"/>
+ <module name="MutableException"/>
+ <module name="ThrowsCount">
+ <property name="max" value="5"/>
+ </module>
+ <module name="VisibilityModifier">
+ <property name="protectedAllowed" value="true"/>
+ <property name="packageAllowed" value="true"/>
+ </module>
+
+
+ <!-- Metrics checks. -->
+ <!-- See http://checkstyle.sf.net/config_metrics.html -->
+ <module name="BooleanExpressionComplexity">
+ <property name="max" value="6"/>
+ </module>
+ <!--<module name="ClassDataAbstractionCoupling"/>-->
+ <!--<module name="ClassFanOutComplexity"/>-->
+ <!--<module name="CyclomaticComplexity"/>-->
+ <!--<module name="NPathComplexity"/>-->
+ <module name="JavaNCSS">
+ <property name="methodMaximum" value="75"/>
+ </module>
+
+
+ <!-- Miscellaneous other checks. -->
+ <!-- See http://checkstyle.sf.net/config_misc.html -->
+ <!--
+ <module name="ArrayTypeStyle"/>
+ <module name="FinalParameters"/>
+ -->
+ <!--
+ <module name="GenericIllegalRegexp">
+ <property name="format" value="\s+$"/>
+ <property name="message" value="Line has trailing spaces."/>
+ </module>
+ -->
+ <module name="TodoComment">
+ <property name="format" value="WARNING"/>
+ </module>
+
+ <module name="UpperEll"/>
+
+ <!--Assert statement may have side effects:-->
+ <module name="DescendantToken">
+ <property name="tokens" value="LITERAL_ASSERT"/>
+ <property name="limitedTokens"
+ value="ASSIGN,DEC,INC,POST_DEC,POST_INC,PLUS_ASSIGN,MINUS_ASSIGN,STAR_ASSIGN,DIV_ASSIGN,MOD_ASSIGN,BSR_ASSIGN,SR_ASSIGN,SL_ASSIGN,BAND_ASSIGN,BXOR_ASSIGN,BOR_ASSIGN"/>
+ <property name="maximumNumber" value="0"/>
+ </module>
+
+ <!--<module name="UncommentedMain"/>-->
+ <!-- <module name="TrailingComment"/>-->
+ <module name="Indentation">
+ <property name="caseIndent" value="4"/>
+ </module>
+ <!--<module name="RequiredRegexp">-->
+ </module>
+
+</module>
Propchange: incubator/tuscany/sandbox/jboynes/sca/tuscany-checkstyle.xml
------------------------------------------------------------------------------
svn:eol-style = native
Propchange: incubator/tuscany/sandbox/jboynes/sca/tuscany-checkstyle.xml
------------------------------------------------------------------------------
svn:keywords = Rev,Date
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-commits-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-commits-help@ws.apache.org
Re: Checkstyle sandbox commit review/thoughts....
Posted by Jim Marino <jm...@myromatours.com>.
FYI Dan
I switched awhile back from Eclipse (I was a long-time user) to
IntelliJ and I love it. It takes a bit getting used to the key
mappings but the refactoring capabilities are just awesome. I'm also
amazed at the things it can catch from analyzing code. And even
better, JetBrains offers free open source licenses so you can pick
one up if you like it.
Jim
On Jun 10, 2006, at 2:44 PM, Daniel Kulp wrote:
> Jeremy,
>
>
>> Dan, what's the Eclipse issue with ruleset? Is it a Eclipse extension
>> thing or something that would impact the main build?
>
> The eclipse PMD plugin has some strange "design flaws" (IMO) that
> make it
> harder to use than it really should be. The main restriction is
> that there
> isn't really a way to set a "global" ruleset that can be referenced
> by the
> project. For example, with the Checkstyle plugin, in our
> workspace we can
> create a named set of checkstyle rules called "Tuscany Checks" that
> points to
> the tuscany-checkstyle.xml file. The ".checkstyle" file in each
> project is
> then very small, it just says "use Tuscany Checks". That way, if the
> tuscany-checkstyle.xml changes, then all projects get the changes.
>
> PMD, on the otherhand, cannot do that. It only sets rules in one
> of two
> ways:
> 1) In the project, there is a ".ruleset" file that defines all the
> rules for
> that project. This means the .ruleset file needs to be copied to ALL
> directories and if you want to change the PMD rules, you need to re-
> copy to
> all directories. (although that does allow different directories
> to have
> different rules)
>
> 2) You configure a bunch of rules in the workspace, but each
> project then
> specifies which of those rules to use in their .pmd file. Thus,
> if you want
> to add a new rule, you need to modify the .pmd file in each
> directory. That
> sucks just as bad.
>
> The PMD maven plugin doesn't suffer the problem. It can use a
> single file
> defined elsewhere (in the buildtools jar) for all the projects. The
> workaround I mentioned was to create a "setup.eclipse" profile that
> unpacks
> the file from that jar and creates the .ruleset file from it.
> Thus, each
> directory doesn't have the .ruleset file checked into svn. It's
> created
> only if you need it for eclipse. The cool thing is the
> "setup.eclipse"
> profile can also generate the .checkstyle and .pmd files at the
> same time so
> those don't get checked in. (just FYI: we are NOT doing this in
> celtix yet.
> I just figured out how to do that workaround last week)
>
> PMD has some other problems as well:
> 1) The MAVEN PMD plugin cannot check the test sources. It can
> ONLY be
> configured to test src/main/java. I've already logged a bug on
> that.
>
> 2) The ECLIPSE PMD plugin cannot be configured to NOT check the
> generated
> sources. This is a real killer for projects that have generated
> artifacts.
> In general, generated artifacts rarely meet all the .pmd
> requirements unless
> the .pmd requirements aren't very strict. For Celtix, we use very
> few PMD
> rules so the JAXB generated code passes.
>
> 3) PMD is pretty slow. Checkstyle is about the same speed as
> Javac. If you
> configure a bunch of PMD rules, it can take a LONG time. However,
> because
> of (2), we don't configure many rules so it's not too bad.
>
>
> Anyway, those are all PMD issues, not Checkstyle. The checkstyle
> stuff works
> quite well. You can tell Checkstyle to check only ^src/**/*.java
> so the
> stuff in target/generated is ignored. You can use a "named"
> config file so
> each project doesn't need one. It's also relatively quick
> (compared to
> PMD).
>
>
>> Or a somewhat related note, does anyone have any experience with the
>> Jetstyle IDEA plugin (or another way of integrating this with IDEA)?
>
> Haven't tried it yet. I just started trying out IDEA on
> Wednesday. I'm
> investigating if it can help with some big "Celtix refactorings"
> that we're
> working on, but it hung when I tried to do a major refactor (change
> the
> package names for EVERYTHING). (That said, eclipse didn't fare
> much better)
>
>
> --
> J. Daniel Kulp
> Principal Engineer
> IONA
> P: 781-902-8727 C: 508-380-7194 F:781-902-8001
> daniel.kulp@iona.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Checkstyle sandbox commit review/thoughts....
Posted by Daniel Kulp <da...@iona.com>.
Jeremy,
> Dan, what's the Eclipse issue with ruleset? Is it a Eclipse extension
> thing or something that would impact the main build?
The eclipse PMD plugin has some strange "design flaws" (IMO) that make it
harder to use than it really should be. The main restriction is that there
isn't really a way to set a "global" ruleset that can be referenced by the
project. For example, with the Checkstyle plugin, in our workspace we can
create a named set of checkstyle rules called "Tuscany Checks" that points to
the tuscany-checkstyle.xml file. The ".checkstyle" file in each project is
then very small, it just says "use Tuscany Checks". That way, if the
tuscany-checkstyle.xml changes, then all projects get the changes.
PMD, on the otherhand, cannot do that. It only sets rules in one of two
ways:
1) In the project, there is a ".ruleset" file that defines all the rules for
that project. This means the .ruleset file needs to be copied to ALL
directories and if you want to change the PMD rules, you need to re-copy to
all directories. (although that does allow different directories to have
different rules)
2) You configure a bunch of rules in the workspace, but each project then
specifies which of those rules to use in their .pmd file. Thus, if you want
to add a new rule, you need to modify the .pmd file in each directory. That
sucks just as bad.
The PMD maven plugin doesn't suffer the problem. It can use a single file
defined elsewhere (in the buildtools jar) for all the projects. The
workaround I mentioned was to create a "setup.eclipse" profile that unpacks
the file from that jar and creates the .ruleset file from it. Thus, each
directory doesn't have the .ruleset file checked into svn. It's created
only if you need it for eclipse. The cool thing is the "setup.eclipse"
profile can also generate the .checkstyle and .pmd files at the same time so
those don't get checked in. (just FYI: we are NOT doing this in celtix yet.
I just figured out how to do that workaround last week)
PMD has some other problems as well:
1) The MAVEN PMD plugin cannot check the test sources. It can ONLY be
configured to test src/main/java. I've already logged a bug on that.
2) The ECLIPSE PMD plugin cannot be configured to NOT check the generated
sources. This is a real killer for projects that have generated artifacts.
In general, generated artifacts rarely meet all the .pmd requirements unless
the .pmd requirements aren't very strict. For Celtix, we use very few PMD
rules so the JAXB generated code passes.
3) PMD is pretty slow. Checkstyle is about the same speed as Javac. If you
configure a bunch of PMD rules, it can take a LONG time. However, because
of (2), we don't configure many rules so it's not too bad.
Anyway, those are all PMD issues, not Checkstyle. The checkstyle stuff works
quite well. You can tell Checkstyle to check only ^src/**/*.java so the
stuff in target/generated is ignored. You can use a "named" config file so
each project doesn't need one. It's also relatively quick (compared to
PMD).
> Or a somewhat related note, does anyone have any experience with the
> Jetstyle IDEA plugin (or another way of integrating this with IDEA)?
Haven't tried it yet. I just started trying out IDEA on Wednesday. I'm
investigating if it can help with some big "Celtix refactorings" that we're
working on, but it hung when I tried to do a major refactor (change the
package names for EVERYTHING). (That said, eclipse didn't fare much better)
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194 F:781-902-8001
daniel.kulp@iona.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Checkstyle sandbox commit review/thoughts....
Posted by Jeremy Boynes <jb...@apache.org>.
Daniel Kulp wrote:
>
> 3) The pmd plugin config could also be pushed into the pluginManagement
> section of the top pom. It would make for less copy/paste into each
> sub-pom. Actually, if it wasn't for eclipse, the .ruleset file could go
> into the buildtools module as tuscany-ruleset.xml and sucked in from there
> like checkstyle. I have a "workaround" for the eclipse issue by creating a
> special "mvn -Psetup.eclipse" profile that would need to be used instead
> of "mvn eclipse:eclipse". Not sure we want that though. (basically, the
> profile would suck the tuscany-pmd-ruleset.xml file out of the buildtools jar
> and create the .ruleset on the fly. It can also create the .pmd
> and .checkstyle files on the fly so they aren't checked in in every
> directory. )
>
Dan, what's the Eclipse issue with ruleset? Is it a Eclipse extension
thing or something that would impact the main build?
Or a somewhat related note, does anyone have any experience with the
Jetstyle IDEA plugin (or another way of integrating this with IDEA)?
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Checkstyle sandbox commit review/thoughts....
Posted by Jim Marino <jm...@myromatours.com>.
Yea thanks for pointing this out. I stuck things there since I was
having a bit of trouble getting checkstyle picked up by the lower
projects and figured I wait for your help to sort it out :) One thing
is a relaxed some of the checks (e.g. line length to 120, parameter
names are allowed to mask field names). I'm also getting a bunch of
these types of errors and can't figure out what setting it is:
TuscanyRuntimeException.java:15:5: warning: The field 'identifier'
must be declared final
Any ideas?
Some comments inline too...
On Jun 10, 2006, at 12:43 AM, Daniel Kulp wrote:
>
> Jim,
>
> Couple notes about your checkstyle commit..... (I know it's still
> early and
> you are just beginning to add it, but reviews are good anytime. :-)
>
> 1) You shouldn't need to put the tuscany-checkstyle.xml file into each
> directory. The purpose of the "buildtools" module is to create a
> jar that
> holds that file which we can then "depend" on in the other places it's
> needed. The checkstyle plugin should then be able to pull it from
> that jar.
> This method of doing it was taken from the maven checkstyle tips:
> http://maven.apache.org/plugins/maven-checkstyle-plugin/tips.html
>
> 2) Also, I had put it "top level" (in java, not sca) as I thought
> it would
> make sense to eventually get the ENTIRE tuscany project on one set
> of rules,
> including the specs and SDO projects. Not a huge deal
> though. I was
> just hoping to foster a more "across the entire tuscany project"
> type of
> thing.
>
For the SCA specs I don't see problem doing this. For the others such
as SDO and DAS, I think that is up to them.
> 3) The pmd plugin config could also be pushed into the
> pluginManagement
> section of the top pom. It would make for less copy/paste into each
> sub-pom. Actually, if it wasn't for eclipse, the .ruleset file
> could go
> into the buildtools module as tuscany-ruleset.xml and sucked in
> from there
> like checkstyle. I have a "workaround" for the eclipse issue by
> creating a
> special "mvn -Psetup.eclipse" profile that would need to be used
> instead
> of "mvn eclipse:eclipse". Not sure we want that though.
> (basically, the
> profile would suck the tuscany-pmd-ruleset.xml file out of the
> buildtools jar
> and create the .ruleset on the fly. It can also create the .pmd
> and .checkstyle files on the fly so they aren't checked in in every
> directory. )
>
>
> OK, A few notes, not a couple. :-)
>
Thanks. I'm going to try and sort these out today if I get time, if
not next week since I'm flying out tomorrow. I'll probably bug you
when I get stuck.
> Nice job though. I'm glad to see the code becoming a bit cleaner
> and more
> consistent.
>
> Enjoy!
>
> --
> J. Daniel Kulp
> Principal Engineer
> IONA
> P: 781-902-8727 C: 508-380-7194 F:781-902-8001
> daniel.kulp@iona.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Checkstyle sandbox commit review/thoughts....
Posted by Daniel Kulp <da...@iona.com>.
Jim,
Couple notes about your checkstyle commit..... (I know it's still early and
you are just beginning to add it, but reviews are good anytime. :-)
1) You shouldn't need to put the tuscany-checkstyle.xml file into each
directory. The purpose of the "buildtools" module is to create a jar that
holds that file which we can then "depend" on in the other places it's
needed. The checkstyle plugin should then be able to pull it from that jar.
This method of doing it was taken from the maven checkstyle tips:
http://maven.apache.org/plugins/maven-checkstyle-plugin/tips.html
2) Also, I had put it "top level" (in java, not sca) as I thought it would
make sense to eventually get the ENTIRE tuscany project on one set of rules,
including the specs and SDO projects. Not a huge deal though. I was
just hoping to foster a more "across the entire tuscany project" type of
thing.
3) The pmd plugin config could also be pushed into the pluginManagement
section of the top pom. It would make for less copy/paste into each
sub-pom. Actually, if it wasn't for eclipse, the .ruleset file could go
into the buildtools module as tuscany-ruleset.xml and sucked in from there
like checkstyle. I have a "workaround" for the eclipse issue by creating a
special "mvn -Psetup.eclipse" profile that would need to be used instead
of "mvn eclipse:eclipse". Not sure we want that though. (basically, the
profile would suck the tuscany-pmd-ruleset.xml file out of the buildtools jar
and create the .ruleset on the fly. It can also create the .pmd
and .checkstyle files on the fly so they aren't checked in in every
directory. )
OK, A few notes, not a couple. :-)
Nice job though. I'm glad to see the code becoming a bit cleaner and more
consistent.
Enjoy!
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194 F:781-902-8001
daniel.kulp@iona.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org