Maven is great if you have an application with a lot of third-party dependencies and don’t want each developer to keep track of where the dependency can be downloaded. It’s also a great way to make it easy for a new developer to be able to build the application. It’s less suitable for simple projects without any third-party dependencies.
As an open source rule engine and product suite, Drools is well suited for the small and middle scale business to manage and integrate the rules to build the rule-driven system which can process the business-critical data and events to produce the automated decision. It is better to use Drools in the well-secured environment (back-end behind the DMZ), not putting it on the customer-facing front or exposing it directly the to public where may bring direct security risk in the enterprise environment. Drools still needs a lot hardening on the security side.
Maven provides a very rigid model that makes customization tedious and sometimes impossible. While this can make it easier to understand any given Maven build, as long as you don’t have any special requirements, it also makes it unsuitable for many automation problems.
Maven has few, built-in dependency scopes, which forces awkward module architectures in common scenarios like using test fixtures or code generation. There is no separation between unit and integration tests
Fusion doesn't support persistence of working memory, which brings some extra high availability risk to our business.
Guvnor still has a lot room to be implemented, it is not so user-friendly for non-technical people, so a lot of business users complain it is hard to master.
Rule execution server doesn't even have JMX implemented, hard to be monitored.
Drools is still lacking support for key Web services standards.
The overall usability of Apache Maven is very good to us. We were able to incorporate it into our company's build process pretty quickly. We deployed it to multiple teams throughout the entire enterprise. We got good feedback from our developers stating that Apache Maven has simplified their build process. It also allowed to to standardize the build process for the entire enterprise, thus ensure that each development team is using the same, consistent process to build code.
I can't speak to the support, as I've never had issues. Apache Maven "just works," and errors were user errors or local nexus errors. Apache Maven is a great build/dependency management tool. I give it a 9/10 because occasionally the error message don't immediately indicate a solution...but again, those errors were always user or configuration errors, and the Maven documentation is extensive, so I don't find fault in Maven, but in its users.
Ant, Maven's opposing framework, is often a point of comparison. Although Ant does not require formal conventions, it is procedural in the sense that you must tell Ant exactly what to do and when. It also lacks a lifecycle, along with goal definition and dependencies. Maven, on the other hand, requires less work as it knows exactly where your source code is as long as the pom.xml file is generated.
Apache Maven is an open source product from the Apache Software Foundation. Being free to use without any licensing constraints, we've been very happy with this product thus far.
The software build and packaging times for our applications have improved greatly since our use of this tool.
The IT department quickly adopted Drools as it is a very good java-based rule engine, which saves a lot of time to meet the project timeline and balanced our business requirements.
Recently we start considering the OpenRules, which may be more business user-friendly.
