We've recently picked up PMD on our Salesforce project to help with our Apex code quality analysis. We've implemented a couple of rules, but have seen that most of the really valuable-looking rules (around performance, complexity, etc) are marked as deprecated.
Do people generally use continue to use deprecated rules (as they still work, even if they are no longer actively supported)? Or does deprecated in this sense mean that these may be broken/unreliable.
Does the prevalence of deprecated PMD rules mean that we should be looking for an alternative tool?
I'd really welcome your thoughts
There are very few deprecated rules in the Apex module: https://pmd.github.io/latest/pmd_rules_apex.html
PMD rules are usually not deprecated without a replacement. For instance AvoidDmlStatementsInLoops is replaced by OperationWithLimitsInLoops, as documented.
Sometimes several rules are consolidated into a single one, which is the case for those 3 performance rules. You might get the impression that many rules are deprecated, but no functionality is lost, and the newer rules are generally more easily extensible.
If you are seeing many deprecation warnings, it may be because you are referencing those rules through deprecated rulesets. For instance, if you write
<rule ref="rulesets/apex/complexity.xml/AvoidDeeplyNestedIfStmts" />
you will get a deprecation warning, as the ruleset will be removed in PMD 7. However, the rule is not deprecated, and is still accessible at
<rule ref="category/apex/design.xml/AvoidDeeplyNestedIfStmts" />
I'm suggesting this because you mention deprecated complexity rules, and no complexity rules of PMD Apex are deprecated (the ruleset complexity.xml is though).
In PMD 6, PMD's rule library has been reorganized into "categories", in contrast with the previous approach of publishing rulesets directly. Consequently, most built-in rulesets have been deprecated until PMD 7, which does not mean the rules themselves are deprecated.
Related
We are using Drools in a Java 11 Web application via the kie-spring library.
This library depends on xstream.
The compatibility of xstream with newer Java versions is uncertain as described in this Issue which is already 3 years old and not going to be "fixed" as far as I understand it.
Is there a plan to switch to a different underlying technology or any other changes that would move away from xstream? Or at least a way to get rid of the JVM warning and assurance that it will work with future versions?
This is an XStream problem. The very link which is shared in the original question, provide some valid solutions to avoid the mentioned XStream issue.
Is there [...] at least a way to
get rid of the JVM warning and assurance that it will work with future
versions?
As can be seen on this change https://github.com/kiegroup/drools/pull/2988#issuecomment-658079653 modifications are already underway to resolve the mentioned issue as it manifests inside the Drools project which make use of the XStream library.
So this is resolved currently for the Drools' DMN module, and Kogito; if you spotted a specific module of Drools which is not yet updated, you are encouraged to raise a JIRA.
Question on StackOverflow is one of the channel we monitor as #schrobe correctly commented here; if you need a more back/forth exchange you can also interact with Drools developers via chat or forum. All these are valid channel that we monitor as originally described in the project get help page.
I hope this fully answers your original question, let us know if you noticed the issue in other modules!
I heard that SystemJS implements a web standard. Does anyone know which standard it implements?
I assume when this web standard is implemented in browsers SystemJS will no longer be necessary. When is this likely to happen?
Or is my understanding wrong?
SystemJS implements roughly what the WHATWG Loader spec proposes, however there are some ongoing discussions, some of which were implemented in SystemJS albeit not being in the WHATWG spec. Currently, there is no finalized specification of what a module loading system should look like, but most browsers are currently working on something which looks quite similar and is even somewhat compatible.
Currently, <script type="module"> is what most browsers are working on. Chromium/Chrome scheduled the release for version 61, the Firefox developers also seem to work on it, and I believe Safari already shipped it. The main issue currently appears to be that some thing were not properly specified up front, meaning that they cannot just implement what the spec says, but have to improve the spec while implementing (see the linked tickets and associated tickets for details).
Additional ongoing specification work can be found inside the ECMAScript Harmony modules wiki page.
I'm in the process of creating my own wro4j plugin for SBT as my project has some special requirements not achievable with xsbt-wro4j-plugin directly.
I checked the source code of xsbt-wro4j-plugin (here) and also the wro4j API documentation to gain some insight into the file creating process but I'm a bit puzzled here. As far as I can tell the plugin uses Mockito to produce the necessary resources somehow but I don't get how it cooperates with wro4j itself. If I'm right this whole Mockito stuff is a hack so we can use SBT's caching mechanism.
Question #1 is whether we can avoid this Mockito voodoo without losing caching support.
Question #2: what is responsible for file creation within wro4j? Could I override it?
This is not necessarily an answer for all of your questions, but an explanation for the reason xsbt wro4j plugin (and wro4j-maven-plugin) uses mockito.
The wro4j was created initially as a runtime solution only (using HttpServletFilter) to minimize static resources on the fly. As result, the internal API is based on servlet-api (more specifically HttpServletRequest & HttpServletResponse objects). Later, when a build-time solution was required, instead of changing the internals of the framework, a suitable workaround was applied: using a mechanism for stubbing servlet-api in a non servlet environment (build-time).
The way I see the long term approach: is to make wro4j, servlet-api agnostic and allow build-time solutions like maven plugin or xsbt plugin, to not require using this workaround. Unfortunately, in order to do that, the internals of the wro4j should be changed and that would require a major release (incompatible with previous versions). Given the amount of work required to do that, most probably this will be delayed.
I'm new to the world of business rules, but I think I've understood the concepts of Drools Expert and Drools Guvnor, yet I'm still a bit confused how/when/why exactly use Guvnor in comparison to Expert. And also, whether they rule each other out or are capable or even prefered to work side-by-side. Below are some highlighted topics that puzzle and a bit of explanation behind my concerns, mainly concentrating in application maintainability.
Does Guvnor have all the functionality that is available in Expert plus more?
I know that Guvnor is Business Rule Management System (BRMS) that takes control of storing(including versioning) the rules and exposing services to use of other apps. Guvnor contains UIs (text and graphical) for generating the rules and an engine for running them, so in this sense I guess it contains all functionality of the Expert system. Based on my requirements, I'm quite sure Guvnor is what I need, but do I need Drools Expert for anything after that?
Or in other words, does Drools Expert offer something that is not present in Guvnor?
Testing rules in Guvnor
Many tutorials on Drools I've seen start with TDD example where the rules are tested with simple jUnit tests. Once a rule is imported to Guvnor (or just generated there), is there any way to use/write unit tests for it?
Should the testing be done via exposed interfaces (REST) only?
If the users of the system are to develop their own rules, I don't expect them to write any tests. Mainly interested in 'core' rules and their maintainability here.
In case of 'core' rules, should they be stored in a version controlling system and imported to Guvnor on scheduled updates for the complete system? In this case the unit tests could be written for these rules and automatically executed as part of build cycle.
Thanks in advance.
Based on one of your questions, there's something I should clear up first. In essence:
Expert is a rules engine runtime.
Guvnor is a tool for writing and storing rules, which will subsequently be executed in Expert.
Guvnor doesn't provide a runtime for your rules, other than what is required for the test harnesses. You will always need Expert for your runtime environment. Guvnor enables you to manage the rules and store them. It also provides some handy GUI tools such as the guided editor and web decision tables. However, you can also edit rules in an IDE such as Eclipse and push them to Guvnor using the Guvnor WebDav Eclipse plugins.
Typically, you will have a Guvnor web application on one server and your application(s) on elsewhere. You can download the compiled rules from Guvnor into your application build, and deploy them with your application. Alternatively, you can define a URL resource in your code to create your knowledge base, pointing at the Guvnor package URL. In that case, your application can load the knowledge base on start-up and reload it at runtime.
For example the following code will download a package snapshot called "Approved" as a resource for building a knowledge base.
UrlResource urlResource =
(UrlResource) ResourceFactory.newUrlResource(
"http://my.guvnor.local/.../package/mypackage/Approved");
urlResource.setBasicAuthentication("enabled");
urlResource.setUsername("myusername");
urlResource.setPassword("mypassword");
KnowledgeBuilder builder = KnowledgeBuilderFactory.newKnowledgeBuilder();
builder.add(urlResource, resource.getType());
Edit - Take a look at KnowledgeAgent if you wish to have rules reloaded at runtime when they are changed in Guvnor.
My main reason for using Guvnor is to enable non-technical users to author rules using decision tables and DSL-based guided editors.
I like to edit technical rules in Eclipse, where I can easily write unit tests around them and evaluate that they are behaving as I expect. I find that much easier than the testing capabilities in Guvnor. And although Guvnor provides some version control, I much prefer Subversion/Git as version control for my technical rules.
I also write DSL in Eclipse, which I then deploy to Guvnor. This makes guided rules much simpler to work with for non-technical users.
Testing rules
With regards testing, there are a few options. There is testing functionality in Guvnor, which enables you to write expectations based on various inputs. However, I personally find that way too clunky and limiting to use. I far prefer to write tests in Java/JUnit.
First of all, you can write simple unit tests, which load one or two technical rules, written in DRL and evaluate that they are activating when you think they should, and generating inferred facts where appropriate.
For more complex testing, I write tests which create a knowledge base using a package in Guvnor, insert facts and fire rules, in order to evaluate that the package as a whole is working correctly, including those rules which have been built in guided editors or decision tables.
Other uses for Guvnor
It's worth noting that the Guvnor editor functionality is becoming much richer, and it is becoming an editor and repository for more than just rules. For instance, there is rich tooling for BPM processes, which should soon be better than what you can get in an IDE such as Eclipse.
Summary
If all your rules are written by yourself and other developers in DRL, then there is little benefit to using Guvnor. In fact I would find it a hindrance. However, if you wish to take advantage of the guided editors or decision tables, or you wish to have 'business' users manage some of the rules, then you should take a deeper look at Guvnor.
If we need to use plugaable rule engine, what are all the open standards related to it.
How to migrate rule engine "without rewriting rules" for every platform?
JSR-94 is the only standard in wide use but, sadly, won't help you with rewriting rules as it is only a standard for calling the engine. If you want to avoid re-writing rules while either supporting multiple rule engines or moving from one to another then you need to look into a couple of other standards:
Production Rule Representation (PRR) is a standard under development at OMG. This defines the basic structure of rules and rulesets in rule engines so that an XML structure can be passed around containing rules. This is in beta and is being supported by most of the major rule vendors (though I don't think any have released support yet).
Rule Interchange Format (RIF) is a standard under development at W3C. This is being kept synchronized with PRR and is focused on the syntax of the rules - how to specify conditions etc. This is also widely supported but similarly support is not yet released.
The idea, and the reason the two teams work together, is to allow rules to be structured according to PRR (allowing them to be shared between modeling tools and rule engines) while exporting the rule engine-specific syntax to RIF so that specific rules can be moved from syntax to syntax.
Wikipedia says
Most Java-based rules engines provide
a technical call-level interface,
based on the JSR-94 application
programming interface (API) standard,
in order to allow for integration with
different applications, and many rule
engines allow for service-oriented
integrations through Web-based
standards such as WSDL and SOAP.
In general, it's still an early stage and I don't think there's still a dominating standard on the field. Also see The Rule Markup Initiative (RuleML). Besides JSR-94 and RuleML, Business Rule Management System mentions OMG Business Motivation Model (BMM), OMG SBVR, OMG Production Rule Representation (PRR), W3C RIF, and PMML.
You may also be interested in topics like BPEL, workflow engine, workflow application, and business process management.