The new pmd-designer 6.19.0 adds the language module "text" (PlainText).
It is used as a fallback, if no other language modules are on the
classpath.
With this change PMD only logs a warning
if the file categories.properties couldn't be found for a language
instead of throwing RuleSetNotFoundException.
Refs #2082
Not all cases are solved yet. It works, if a rule has been renamed
within the same category. If a rule is moved between categories,
then we might get multiple deprecation warnings.
There is also one important change when referencing a complete ruleset:
Previously we skipped all rules, that were deprecated without
distinguishing between rule definitions and rule references.
Now we only skip deprecated rule references but we still use
deprecated rule definitions. This affects any user, that simply uses
a "bulk-import" of category rulesets, because now, they'll also
use deprecated rules and get a warning. They'd need to exclude these
rules explicitly (or import just the rules they want to use).
Fixes#2048
All XPath rules will have now type resolution enabled by default.
While this change is in core, it actually only affects Java, since
this is the only language which has a type resolution facade
registered in its language handler.
The github release is first created as a draft, when we edit
the release notes, we publish it (draft=false), so that the
release notification mail contains the full release notes.
There seems to be some problem when the deploy phase is executed,
which happens only on pushes - for PRs the deploy is not executed
at all.
Although the deploy is skipped (since this is not a tagged build),
the windows job hangs after that.
Maybe we need to deploy to github releases manually, as we do
for the release notes already. That way, we wouldn't use the
deployment mechanism of travis.
Fixes#1531
In case we determined, that the method argument is a method call,
then we skip now completly trying to determine the correct argument
type. It was half-way fixed before for the first if condition, but
we still evaluated e.g. the allocation expression in
print(new Integer(1).toString());
and wrongly assumed, the argument type would be an integer,
without taking into account the `toString()` method call.
The same happened with
privateBooleanMethod(s, "true".equals(s));
where we took the 2nd argument as a literal and assumed
it is a "String", while the method call result actually
is a boolean.
With this change now, the false positive is fixed.
However, since we don't determine the argument type at all, the
method is matched solely on argument count. This will obviously
lead to wrong matches if method overloading is used.
