diff --git a/feed.xml b/feed.xml
index e13ec91993..c9d81005b1 100644
--- a/feed.xml
+++ b/feed.xml
@@ -5,8 +5,8 @@
Intended as a documentation theme based on Jekyll for technical writers documenting software and other technical products, this theme has all the elements you would need to handle multiple products with both multi-level sidebar navigation, tags, and other documentation features.
https://pmd.github.io/pmd/
- Sat, 27 Mar 2021 14:40:22 +0000
- Sat, 27 Mar 2021 14:40:22 +0000
+ Sat, 27 Mar 2021 15:42:22 +0000
+ Sat, 27 Mar 2021 15:42:22 +0000Jekyll v3.9.0
diff --git a/index.html b/index.html
index 143496b55f..c9a6a20f6f 100644
--- a/index.html
+++ b/index.html
@@ -173,7 +173,7 @@
[tom@hal building]$ ls -l
total 5716
--rw-rw-r-- 1 tom tom 5837216 Jul 17 13:09 pmd-src-6.33.0-SNAPSHOT.zip
-[tom@hal building]$ unzip -q pmd-src-6.33.0-SNAPSHOT.zip
+-rw-rw-r-- 1 tom tom 5837216 Jul 17 13:09 pmd-src-6.33.0.zip
+[tom@hal building]$ unzip -q pmd-src-6.33.0.zip
[tom@hal building]$
Now cd down into the pmd directory:
-
[tom@hal building]$ cd pmd-src-6.33.0-SNAPSHOT
-[tom@hal pmd-src-6.33.0-SNAPSHOT]$ ls -l | grep pom.xml
+
[tom@hal building]$ cd pmd-src-6.33.0
+[tom@hal pmd-src-6.33.0]$ ls -l | grep pom.xml
-rw-rw-r-- 1 tom tom 36482 14\. Nov 17:36 pom.xml
-[tom@hal pmd-src-6.33.0-SNAPSHOT]$
+[tom@hal pmd-src-6.33.0]$
That’s the project configuration for maven… let’s compile!
The framework is pretty simple. On a high level, a Metric<N> describes some numeric computation on a node of type N.
-You should wrap it into a MetricKey<N>, so that it can be cached on nodes (implemented by MetricsUtil).
+You should wrap it into a MetricKey<N>, so that it can be cached on nodes (implemented by MetricsUtil).
At the very least, a metrics framework has those two components and is just a convenient way to compute and memoize
metrics on a single file. The expressive power of metrics can be improved by implementing signature matching capabilities,
@@ -1433,8 +1433,8 @@ harder than it looks, and has been rescheduled to another project.
Implement metrics (typically in an internal package)
Create some public enums/ utility classes to expose metric keys
@@ -1535,25 +1535,29 @@ the breaking API changes will be performed in 7.0.0.
an API is tagged as @Deprecated or not in the latest minor release. During the development of 7.0.0,
we may decide to remove some APIs that were not tagged as deprecated, though we’ll try to avoid it.
+
6.33.0
+
+
No changes.
+
6.32.0
Experimental APIs
-
The experimental class ASTTypeTestPattern has been renamed to ASTTypePattern
+
The experimental class ASTTypeTestPattern has been renamed to ASTTypePattern
in order to align the naming to the JLS.
@@ -1564,7 +1568,7 @@ in order to align the naming to the JLS.
You can identify them with the @InternalApi annotation. You’ll also get a deprecation warning.
The protected or public member of the Java rule AvoidUsingHardCodedIPRule
are deprecated and considered to be internal API. They will be removed with PMD 7.
@@ -1573,17 +1577,17 @@ are deprecated and considered to be internal API. They will be removed with PMD
The method GenericToken#getKind has been added as experimental. This
unifies the token interface for both JavaCC and Antlr. The already existing method
-AntlrToken#getKind is therefore experimental as well. The
+AntlrToken#getKind is therefore experimental as well. The
returned constant depends on the actual language and might change whenever the grammar
of the language is changed.
@@ -1595,30 +1599,30 @@ of the language is changed.
Around RuleSet parsing
-
RuleSetFactory and RulesetsFactoryUtils have been deprecated in favor of RuleSetLoader. This is easier to configure, and more maintainable than the multiple overloads of RulesetsFactoryUtils.
-
Some static creation methods have been added to RuleSet for simple cases, eg forSingleRule. These replace some counterparts in RuleSetFactory
-
Since RuleSets is also deprecated, many APIs that require a RuleSets instance now are deprecated, and have a counterpart that expects a List<RuleSet>.
RuleSetFactory and RulesetsFactoryUtils have been deprecated in favor of RuleSetLoader. This is easier to configure, and more maintainable than the multiple overloads of RulesetsFactoryUtils.
+
Some static creation methods have been added to RuleSet for simple cases, eg forSingleRule. These replace some counterparts in RuleSetFactory
+
Since RuleSets is also deprecated, many APIs that require a RuleSets instance now are deprecated, and have a counterpart that expects a List<RuleSet>.
net.sourceforge.pmd.lang.dart.antlr4.Dart2Lexer will be renamed to DartLexer and moved to package
net.sourceforge.pmd.lang.dart.ast with PMD 7. All other classes in the old package will be removed.
@@ -1853,84 +1857,84 @@ The following usages are now deprecated in the Apex, Ja
Manual instantiation of nodes. Constructors of node classes are deprecated and
-marked InternalApi. Nodes should only be obtained from the parser,
+marked InternalApi. Nodes should only be obtained from the parser,
which for rules, means that they never need to instantiate node themselves.
Those constructors will be made package private with 7.0.0.
Subclassing of abstract node classes, or usage of their type. The base classes are internal API
and will be hidden in version 7.0.0. You should not couple your code to them.
-
In the meantime you should use interfaces like VfNode or
-Node, or the other published interfaces in this package,
+
In the meantime you should use interfaces like VfNode or
+Node, or the other published interfaces in this package,
to refer to nodes generically.
Concrete node classes will be made final with 7.0.0.
Setters found in any node class or interface. Rules should consider the AST immutable.
We will make those setters package private with 7.0.0.
The implementation classes of TokenManager (eg VfTokenManager) are deprecated and should not be used outside of our implementation.
This also affects CPD-only modules.
These deprecations are added to the following language modules in this release.
Please look at the package documentation to find out the full list of deprecations.
Outside of these packages, these changes also concern the following TokenManager
implementations, and their corresponding Parser if it exists (in the same package):
Multiple fields, constructors and methods in XPathRule. See javadoc for details.
6.22.0
@@ -1943,27 +1947,27 @@ implementations, and their corresponding Parser if it exists (in the same packag
You can identify them with the @InternalApi annotation. You’ll also get a deprecation warning.
Many APIs of net.sourceforge.pmd.lang.metrics, though most of them were internal and
+probably not used directly outside of PMD. Use MetricsUtil as
a replacement for the language-specific façades too.
Several methods of ASTTryStatement, replacements with other names
have been added. This includes the XPath attribute @Finally, replace it with a test for child::FinallyStatement.
Several methods named getGuardExpressionNode are replaced with getCondition. This affects the
following nodes: WhileStatement, DoStatement, ForStatement, IfStatement, AssertStatement, ConditionalExpression.
@@ -2038,25 +2042,25 @@ The following usages are now deprecated in the JSP AST (with ot
Manual instantiation of nodes. Constructors of node classes are deprecated and
-marked InternalApi. Nodes should only be obtained from the parser,
+marked InternalApi. Nodes should only be obtained from the parser,
which for rules, means that they never need to instantiate node themselves.
Those constructors will be made package private with 7.0.0.
Subclassing of abstract node classes, or usage of their type. The base classes are internal API
and will be hidden in version 7.0.0. You should not couple your code to them.
-
In the meantime you should use interfaces like JspNode or
-Node, or the other published interfaces in this package,
+
In the meantime you should use interfaces like JspNode or
+Node, or the other published interfaces in this package,
to refer to nodes generically.
Concrete node classes will be made final with 7.0.0.
Setters found in any node class or interface. Rules should consider the AST immutable.
We will make those setters package private with 7.0.0.
@@ -2066,28 +2070,28 @@ The following usages are now deprecated in the VM AST (with oth
Manual instantiation of nodes. Constructors of node classes are deprecated and
-marked InternalApi. Nodes should only be obtained from the parser,
+marked InternalApi. Nodes should only be obtained from the parser,
which for rules, means that they never need to instantiate node themselves.
Those constructors will be made package private with 7.0.0.
Subclassing of abstract node classes, or usage of their type. The base classes are internal API
and will be hidden in version 7.0.0. You should not couple your code to them.
-
In the meantime you should use interfaces like VmNode or
-Node, or the other published interfaces in this package,
+
In the meantime you should use interfaces like VmNode or
+Node, or the other published interfaces in this package,
to refer to nodes generically.
Concrete node classes will be made final with 7.0.0.
Setters found in any node class or interface. Rules should consider the AST immutable.
We will make those setters package private with 7.0.0.
CharStream, JavaCharStream,
+SimpleCharStream: these are APIs used by our JavaCC
implementations and that will be moved/refactored for PMD 7.0.0. They should not
be used, extended or implemented directly.
All classes generated by JavaCC, eg JJTJavaParserState.
This includes token classes, which will be replaced with a single implementation, and
-subclasses of ParseException, whose usages will be replaced
+subclasses of ParseException, whose usages will be replaced
by just that superclass.
@@ -2142,44 +2146,44 @@ by just that superclass.
pmd-core
-
Many methods on the Node interface
-and AbstractNode base class. See their javadoc for details.
Several methods of ASTTryStatement, replacements with other names
have been added. This includes the XPath attribute @Finally, replace it with a test for child::FinallyStatement.
Several methods named getGuardExpressionNode are replaced with getCondition. This affects the
following nodes: WhileStatement, DoStatement, ForStatement, IfStatement, AssertStatement, ConditionalExpression.
Each renderer has now a new method Renderer#setUseShortNames which
is used for implementing the “shortnames” CLI option. The method is automatically called by PMD, if this
CLI option is in use. When rendering filenames to the report, the new helper method
-AbstractRenderer#determineFileName should be used. This will change
+AbstractRenderer#determineFileName should be used. This will change
the filename to a short name, if the CLI option “shortnames” is used.
Not adjusting custom renderers will make them render always the full file names and not honoring the
@@ -2271,19 +2275,19 @@ CLI option “shortnames”.
The method AbstractPMDProcessor#filenameFrom has been
deprecated. It was used to determine a “short name” of the file being analyzed, so that the report
can use short names. However, this logic has been moved to the renderers.
Reminder: Please don’t use members marked with the annotation InternalApi, as they will likely be removed, hidden, or otherwise intentionally broken with 7.0.0.
In ASTs
@@ -2325,17 +2329,17 @@ hide some methods and constructors that rule writers should not have access to.
The following usages are now deprecated in the Java AST (with other languages to come):
-
Manual instantiation of nodes. Constructors of node classes are deprecated and marked InternalApi. Nodes should only be obtained from the parser, which for rules, means that never need to instantiate node themselves. Those constructors will be made package private with 7.0.0.
+
Manual instantiation of nodes. Constructors of node classes are deprecated and marked InternalApi. Nodes should only be obtained from the parser, which for rules, means that never need to instantiate node themselves. Those constructors will be made package private with 7.0.0.
Subclassing of abstract node classes, or usage of their type. Version 7.0.0 will bring a new set of abstractions that will be public API, but the base classes are and will stay internal. You should not couple your code to them.
-
In the meantime you should use interfaces like JavaNode or Node, or the other published interfaces in this package, to refer to nodes generically.
+
In the meantime you should use interfaces like JavaNode or Node, or the other published interfaces in this package, to refer to nodes generically.
Concrete node classes will be made final with 7.0.0.
Setters found in any node class or interface. Rules should consider the AST immutable. We will make those setters package private with 7.0.0.
The DumpFacades in all languages, that could be used to transform a AST into a textual representation,
will be removed with PMD 7. The rule designer is a better way to inspect nodes.
@@ -2380,7 +2384,7 @@ or enable preview language features (e.g. CodeClimateRule is deprecated in 7.0.0 because it was unused for 2 years and
+
CodeClimateRule is deprecated in 7.0.0 because it was unused for 2 years and
created an unwanted dependency.
Properties “cc_categories”, “cc_remediation_points_multiplier”, “cc_block_highlighting” will also be removed.
See #1702 for more.
@@ -2419,59 +2423,59 @@ to remove them in 7.0.0. The proposed changes to the API are described net.sourceforge.pmd.properties.builders,
-is being replaced by the simpler PropertyBuilder. Their APIs enjoy a high degree of source compatibility.
+construction through builders. The builder hierarchy, currently found in the package net.sourceforge.pmd.properties.builders,
+is being replaced by the simpler PropertyBuilder. Their APIs enjoy a high degree of source compatibility.
Concrete property classes like IntegerProperty and StringMultiProperty will gradually
+all be deprecated until 7.0.0. Their usages should be replaced by direct usage of the PropertyDescriptor
interface, e.g. PropertyDescriptor<Integer> or PropertyDescriptor<List<String>>.
-
Instead of spreading properties across countless classes, the utility class PropertyFactory will become
+
Instead of spreading properties across countless classes, the utility class PropertyFactory will become
from 7.0.0 on the only provider for property descriptor builders. Each current property type will be replaced
by a corresponding method on PropertyFactory:
MethodProperty, FileProperty, TypeProperty and their multi-valued counterparts
are discontinued for lack of a use-case, and have no planned replacement in 7.0.0 for now.
@@ -2493,19 +2497,19 @@ are discontinued for lack of a use-case, and have no planned replacement in 7.0.
preferredRowCount is deprecated with no intended replacement. It was never implemented, and does not belong
-in this interface. The methods uiOrder and compareTo(PropertyDescriptor) are deprecated for the
+
preferredRowCount is deprecated with no intended replacement. It was never implemented, and does not belong
+in this interface. The methods uiOrder and compareTo(PropertyDescriptor) are deprecated for the
same reason. These methods mix presentation logic with business logic and are not necessary for PropertyDescriptors to work.
PropertyDescriptor will not extend Comparable<PropertyDescriptor> anymore come 7.0.0.
-
The method propertyErrorFor is deprecated and will be removed with no intended
+
The method propertyErrorFor is deprecated and will be removed with no intended
replacement. It’s really just a shortcut for prop.errorFor(rule.getProperty(prop)).
T valueFrom(String) and String asDelimitedString(T) are deprecated and will be removed. These were
used to serialize and deserialize properties to/from a string, but 7.0.0 will introduce a more flexible
XML syntax which will make them obsolete.
-
isMultiValue and type are deprecated and won’t be replaced. The new XML syntax will remove the need
+
isMultiValue and type are deprecated and won’t be replaced. The new XML syntax will remove the need
for a divide between multi- and single-value properties, and will allow arbitrary types to be represented.
Since arbitrary types may be represented, type will become obsolete as it can’t represent generic types,
which will nevertheless be representable with the XML syntax. It was only used for documentation, but a
new way to document these properties exhaustively will be added with 7.0.0.
-
errorFor is deprecated as its return type will be changed to Optional<String> with the shift to Java 8.
+
errorFor is deprecated as its return type will be changed to Optional<String> with the shift to Java 8.
Deprecated APIs
@@ -2536,27 +2540,27 @@ new way to document these properties exhaustively will be added with 7.0.0.
-
The implementation of the adapters for the XPath engines Saxon and Jaxen (package net.sourceforge.pmd.lang.ast.xpath)
-are now deprecated. They’ll be moved to an internal package come 7.0.0. Only Attribute remains public API.
+
The implementation of the adapters for the XPath engines Saxon and Jaxen (package net.sourceforge.pmd.lang.ast.xpath)
+are now deprecated. They’ll be moved to an internal package come 7.0.0. Only Attribute remains public API.
The method getVariableName on those two nodes will be removed, too.
@@ -2586,7 +2590,7 @@ also been deprecated:
All these are deprecated because those nodes may declare several variables at once, possibly
-with different types (and obviously with different names). They both implement Iterator<ASTVariableDeclaratorId>
+with different types (and obviously with different names). They both implement Iterator<ASTVariableDeclaratorId>
though, so you should iterate on each declared variable. See #910.
@@ -2604,25 +2608,25 @@ are not fully supported by PMD, so having a language module does not make sense.
not affected by this change. The following classes have been deprecated and will be removed with PMD 7.0.0:
@@ -2631,12 +2635,12 @@ in 7.0.0 to factorise common logic and make them extensible. Further explanation
found on #1426. Consequently, the following APIs are deprecated for
removal:
@@ -1509,7 +1509,7 @@ By far the most common problem is the use of ${project.version} in a BOM or pare
...
<dependency>
...
- <version>6.33.0-SNAPSHOT</version>
+ <version>6.34.0-SNAPSHOT</version></dependency></project>
In order to change the heap size under Windows, you’ll need to edit the batch file cpd.bat or
set the environment variable PMD_JAVA_OPTS prior to starting CPD:
-
C:\ > cd C:\pmd-bin-6.33.0-SNAPSHOT\bin
+
C:\ > cd C:\pmd-bin-6.33.0\bin
C:\...\bin > set PMD_JAVA_OPTS=-Xmx512m
C:\...\bin > .\cpd.bat --minimum-tokens 100 --files c:\temp\src
Properties can be built using type-specific builders, which can be obtained
-from the factory methods of PropertyFactory. For example, to build a
+from the factory methods of PropertyFactory. For example, to build a
string property, you’d call
PropertyFactory.stringProperty("myProperty").desc("This is my property")
@@ -1475,8 +1475,8 @@ information about how to migrate.
The positive method is part of
+the NumericConstraints class, which provides some
other constraints. The constraint mechanism will be completely unlocked with 7.0.0,
since we’ll be migrating our API to Java 8.
@@ -1507,7 +1507,7 @@ There are several things to notice here:
The property descriptors are declared static final, which should generally be
the case, as descriptors are immutable and can be shared between instances of the same rule;
The property is declared using definePropertyDescriptor` in the constructor,
which ensures the property gets recognised by PMD at the time the properties
are overridden (which happens before rule execution);
The value of the property is not retrieved in the constructor, but in one of
diff --git a/pmd_userdocs_extending_designer_reference.html b/pmd_userdocs_extending_designer_reference.html
index 6cfe8f8731..5bdaeb282e 100644
--- a/pmd_userdocs_extending_designer_reference.html
+++ b/pmd_userdocs_extending_designer_reference.html
@@ -173,7 +173,7 @@
@@ -1428,8 +1428,8 @@ a numeric result. In the Java framework, metrics can be computed on operation de
method declaration), and type declaration nodes (class, interface, enum, and annotation declarations). A metric
object in the framework can only handle either types or operations, but not both.
-
PMD ships with a library of already implemented metrics. These metrics are referenced by MetricKey objects,
+which are listed in two public enums: JavaClassMetricKey and JavaOperationMetricKey.
Metric keys wrap a metric, and know which type of node their metric can be computed on. That way, you cannot compute an operation metric on a class
declaration node. Metrics that can be computed on both operation and type declarations (e.g. NCSS) have one metric key in
each enum.
The metric key does not exist (the name is case insensitive) or is not defined for the type of the context node.
@@ -1462,7 +1462,7 @@ CYCLO’s only defined for methods and constructors.
For Java Rules
-
The static façade class JavaMetrics is the single entry point to compute metrics in the Java framework.
+
The static façade class JavaMetrics is the single entry point to compute metrics in the Java framework.
This class provides the method get and its overloads. The following sections describes the interface of this class.
@@ -1490,7 +1490,7 @@ to JavaMetrics.get.Capability checking
Metrics are not necessarily computable on any node of the type they handle. For example, Cyclo cannot be computed on
-abstract methods. Metric keys provides a supports(Node) boolean method
+abstract methods. Metric keys provides a supports(Node) boolean method
to find out if the metric can be computed on
the specified node. If the metric cannot be computed on the given node, JavaMetrics.get will return Double.NaN .
If you’re concerned about that, you can condition your call on whether the node is supported or not:
@@ -1511,7 +1511,7 @@ If you’re concerned about that, you can condition your call on whether the nod
gathered inside an enum in the implementation class of the metric, for example CycloMetric.CycloOption. They’re
also documented on the index of metrics.
-
To use options with a metric, you must first bundle them into a MetricOptions object. MetricOptions provides the
+
To use options with a metric, you must first bundle them into a MetricOptions object. MetricOptions provides the
utility method ofOptions to get a MetricOptions bundle from a collection or with varargs parameters. You can then
pass this bundle as a parameter to JavaMetrics.get:
@@ -1437,9 +1437,9 @@ very similar for other languages.
To write a rule in Java you’ll have to:
-
write a Java class that implements the interface Rule. Each
+
write a Java class that implements the interface Rule. Each
language implementation provides a base rule class to ease your pain,
-e.g. AbstractJavaRule.
compile this class, linking it to PMD APIs (eg using PMD as a maven dependency)
bundle this into a JAR and add it to the execution classpath of PMD
declare the rule in your ruleset XML
@@ -1467,7 +1467,7 @@ by default just visits the children.
Generally, a rule wants to check for only some node types. In our XPath example
in Your First Rule,
we wanted to check for some VariableDeclaratorId nodes. That’s the XPath name,
-but in Java, you’ll get access to the ASTVariableDeclaratorId
+but in Java, you’ll get access to the ASTVariableDeclaratorId
full API.
If you want to check for some specific node types, you can override the
@@ -1515,7 +1515,7 @@ speed-up your rule by using the rulechain.
That mechanism doesn’t recurse on all the tree, instead, your rule will only be
passed the nodes it is interested in. To use the rulechain correctly:
-
Your rule must register those node types by calling addRuleChainVisit
+
Your rule must register those node types by calling addRuleChainVisit
in its constructor.
Your visit methods must not recurse! In effect, you should call never
call super.visit in the methods.
@@ -1532,7 +1532,7 @@ by multiple threads.
However, for performance reasons, the rule instances are used for multiple files.
This means, that the constructor of the rule is only executed once (per thread)
and the rule instance is reused. If you rely on a proper initialization of instance
-properties, you can do the initialization e.g. in the visit-method of the ASTCompilationUnit
+properties, you can do the initialization e.g. in the visit-method of the ASTCompilationUnit
node - which is visited first and only once per file. However, this
solution would only work for rules written for the Java language. A language
independent way is to override the method start of the rule.
@@ -1567,11 +1567,11 @@ a different set of files to analyse. Then, for each such file, for each
rule copy:
apply is called with the root
of the AST. That method performs the AST traversal that ultimately calls visit methods.
It’s not called for RuleChain rules.
@@ -1475,10 +1475,10 @@ of the specific thing the rule is trying to flag. Rules then report a violation
Discovering the AST
-
ASTs are represented by Java classes deriving from Node.
+
ASTs are represented by Java classes deriving from Node.
Each PMD language has its own set of such classes, and its own rules about how
these classes relate to one another, based on the grammar of the language. For
-example, all Java AST nodes extend JavaNode.
The element has for local name the value of getXPathNodeName
for the given node
@@ -1457,7 +1457,7 @@ for the given node
This means, that documentation for attributes can be found in our Javadocs. For
example, the attribute @SimpleName of the Java node EnumDeclaration is backed
-by the Java getter getSimpleName.
Returns true if the context node's static Java type is a subtype of the given type. This tests for the resolved type of the Java construct, not the type of the AST node. For example, the AST node for a literal (e.g. 5d) has type ASTLiteral, however this function will compare the type of the literal (eg here, double) against the argument.
Returns true if the context node's static type is exactly the given type. In particular, returns false if the context node's type is a subtype of the given type.
@@ -1490,7 +1490,7 @@ require it to function properly.
-
~ $ cd ~/bin/pmd-bin-6.33.0-SNAPSHOT/bin
+
~ $ cd ~/bin/pmd-bin-6.33.0/bin
~/.../bin $ ./run.sh pmd -d ../../../src/main/java/ -f text -R rulesets/java/quickstart.xml
.../src/main/java/com/me/RuleSet.java:123 These nested if statements could be combined
@@ -1500,7 +1500,7 @@ require it to function properly.
.../src/main/java/com/me/RuleSetWriter.java:66 Avoid empty catch blocks
-
C:\ > cd C:\pmd-bin-6.33.0-SNAPSHOT\bin
+
C:\ > cd C:\pmd-bin-6.33.0\bin
C:\...\bin > .\pmd.bat -d ..\..\src\main\java\ -f text -R rulesets/java/quickstart.xml
.../src/main/java/com/me/RuleSet.java:123 These nested if statements could be combined
@@ -1541,7 +1541,7 @@ directory or a jar or zip file containing the sources.
-
~ $ cd ~/bin/pmd-bin-6.33.0-SNAPSHOT/bin
+
~ $ cd ~/bin/pmd-bin-6.33.0/bin
~/.../bin $ ./run.sh cpd --minimum-tokens 100 --files /home/me/src
Found a 7 line (110 tokens) duplication in the following files:
@@ -1557,7 +1557,7 @@ directory or a jar or zip file containing the sources.
assertEquals(Boolean.TYPE, expressions.get(index++).getType());
-
C:\ > cd C:\pmd-bin-6.33.0-SNAPSHOT\bin
+
C:\ > cd C:\pmd-bin-6.33.0\bin
C:\...\bin > .\cpd.bat --minimum-tokens 100 --files c:\temp\src
Found a 7 line (110 tokens) duplication in the following files:
diff --git a/pmd_userdocs_making_rulesets.html b/pmd_userdocs_making_rulesets.html
index 9bf060ebca..ef00ecf402 100644
--- a/pmd_userdocs_making_rulesets.html
+++ b/pmd_userdocs_making_rulesets.html
@@ -173,7 +173,7 @@
@@ -1431,12 +1431,12 @@ Then you can either copy all “*.jar” files from PMD’s lib folder into one
(ANT_HOME/lib, ${user.home}/.ant/lib) or using the -lib command line parameter.
However, the preferred way is to define a <classpath> for pmd itself and use this classpath when
-adding the PMD Task. Assuming, you have extracted the PMD zip file to /home/joe/pmd-bin-6.33.0-SNAPSHOT,
+adding the PMD Task. Assuming, you have extracted the PMD zip file to /home/joe/pmd-bin-6.33.0,
then you can make use of the PMD Task like this:
<taskdef name="pmd" classname="net.sourceforge.pmd.ant.PMDTask">
<classpath>
- <fileset dir="/home/joe/pmd-bin-6.33.0-SNAPSHOT/lib">
+ <fileset dir="/home/joe/pmd-bin-6.33.0/lib">
<include name="*.jar"/>
</fileset>
</classpath>
@@ -1446,7 +1446,7 @@ then you can make use of the PMD Task like this:
Alternatively, a path can be defined and used via classpathref:
<path id="pmd.classpath">
- <fileset dir="/home/joe/pmd-bin-6.33.0-SNAPSHOT/lib">
+ <fileset dir="/home/joe/pmd-bin-6.33.0/lib">
<include name="*.jar"/>
</fileset>
</path>
@@ -1702,7 +1702,7 @@ make sure you use the XML formatter in the PMD task invocation, i.e.:
need to be configured when defining the task:
<path id="pmd.classpath">
- <fileset dir="/home/joe/pmd-bin-6.33.0-SNAPSHOT/lib">
+ <fileset dir="/home/joe/pmd-bin-6.33.0/lib">
<include name="*.jar"/>
</fileset>
<!-- the custom renderer is expected to be in /home/joe/pmd-addons/com/company/MyRenderer.class -->
@@ -1733,7 +1733,7 @@ Your project needs to be compiled first which happens in the target “compile
<pathelement location="lib/xyz.jar"/>
</path>
<path id="pmd.classpath">
- <fileset dir="/home/joe/pmd-bin-6.33.0-SNAPSHOT/lib">
+ <fileset dir="/home/joe/pmd-bin-6.33.0/lib">
<include name="*.jar"/>
</fileset>
</path>
diff --git a/pmd_userdocs_tools_ci.html b/pmd_userdocs_tools_ci.html
index 7febd971a1..20dd122d66 100644
--- a/pmd_userdocs_tools_ci.html
+++ b/pmd_userdocs_tools_ci.html
@@ -173,7 +173,7 @@