I'm new to Drools and I'm trying to start using different tutorials. Lately I've started those two: https://koziolekweb.pl/2008/10/30/jboss-rules-drools-silnik-regul-biznesowych/ and https://www.youtube.com/watch?v=zQhDe_PT60Y but they're using older Drools and I'm using version 7.62.Final. My errors are within those imports:
import org.drools.RuleBase;
import org.drools.RuleBaseFactory;
import org.drools.StatefulSession;
import org.drools.StatelessSession;
import org.drools.compiler.DroolsParserException;
import org.drools.compiler.PackageBuilder;
import org.drools.rule.Package;
and
import org.drools.StatefulSession;
Have they changed in new version of Drools? How may I change them in the code while using for example PackageBuilder builder = new PackageBuilder(); etc? And where can I find this information if it's available?
Thanks
Those tutorials are written against a very old version of Drools (probably Drools 4 or 5, based on the publish date.) Between Drools 5 and 6 there was effectively a complete rewrite, so the backend of the Drools library is completely different.
The imports you mention no longer exist. They no longer exist because their concepts have fundamentally changed. In Drools 5, we had Rule Bases. In Drools 7, we have Kie Bases. Configurations, defaults, how you load and fire rules ... everything is different. If you want to follow those tutorials, down-rev to Drools 5 ... but you can't go to 6.x or newer.
Your best bet is to completely ignore the tutorials -- which are worthless -- and just read the documentation. The Drools documentation is actually very good, and very in depth. Otherwise if you insist on reading tutorials, make sure that you find tutorials targeting 7 (and the newer version of Drools 7 the better, because after 7.44 or so they started implementing non-backwards compatible changes in minor releases.)
Latest from drools is v7.x. I followed the drools examples from the official repository. Check the examples from https://github.com/kiegroup/drools.git
And make sure you switch to latest branch example 'r7.73.0.Final'
Refer the official documentation. I found it a bit overwhelming to understand it initially.
https://docs.drools.org/7.73.0.Final/drools-docs/html_single/index.html
If you build is complaining that it is not finding these imports the real problem is likely that you do not have the correct maven dependencies in your pom.xml downloaded; I am sure that DROOLS still uses the StatelessSession, StatefulSession, etc.
There are two ways to update your pom.xml to use the correct dependency. Do a search on Google
maven org.drools.StatelessSession
and the first item returned is jar.download.com - which let's you download the JAR containing the StatelessSession class for a specific version of the tool. The sixth entry returned by the search is for https://mvnrepository.com - where these JARs are officially stored - showing you the pom.xml dependency for a specific version. Either way, you should make sure you get the correct version of the JAR specified in the pom.xml or downloaded.
DROOLS, JBPM, KIE, etc. use a BOM (bill of materials) project to specify the version of dependencies across a technology (i.e., so if there are 8 hibernate dependencies all 8 reflect the same version.) Your DROOLS documentation probably lists these versions or has a link to the BOM.
One of the blog you are referring is very old and after that there huge amount of changes in the dependencies. You should try updating your pom.xml file and Java Code accordingly. You can download required dependencies from https://mvnrepository.com/
Can you attach you project here ?
Related
The Situation:
I am working on bringing some old projects up so they comply with my company's upgrade to Java 8. Part of this requirement means upgrading from old versions of Spring to at least Spring version 3.2.3.RELEASE. The project I'm working under uses an ant build script to package everything into a deploy-able ear. I'm not too familiar with many build methods other than maven, so my knowledge on ant related subjects isn't great.
Before the upgrade, the project depended on Spring-1.0.2 and used methods from parts of the dao and orm package, specifically DataAccessException and getSqlMapClientTemplate(). There may be more being used, but those don't seem to have produced errors or I haven't found them yet (and are not included in the scope of this question).
The Issue:
I have downloaded and placed spring-core-3.2.3.RELEASE, spring-jdbc-3.2.3.RELEASE, spring-orm-3.2.3.RELEASE, spring-tx-3.2.3.RELEASE into the project (see fig. 1 and fig. 2). Within many of the classes, we are calling the getSqlMapClientTemplate() method (see line 31 of fig. 3). I have found that, in Spring version 3.2.3, this method should be located in the orm package (source: https://www.javadoc.io/doc/org.springframework/spring-orm/3.2.3.RELEASE). The import for the package is provided on line 17 of fig. 3. My understanding is that, with the correct JAR packaged in and the correct import statement included, the error should go away as it is defined within the project. This, however, does not seem to be the case (see fig. 4). The error states that the method is still not defined.
I might not have enough experience to know where things seem to be going wrong. I'm not really sure what to do, so any information that y'all might have would be awesome. I can provide more information as needed.
The Figures:
fig. 1
fig. 2
fig. 3
fig. 4
I have builds like: 1.0.0-9, 1.0.0-10, 1.0.0-11, 1.0.0-12, etc.
I've configured my dependency like:
[1.0.0,)
Which means that it should use the latest version from the existing ones (ofc which starts with 1.0.0), but instead of using the 1.0.0-12 it used the 1.0.0-9. I think that it's because the 9 is grater then the 1.
Firstly I would like to force the maven to use truly my latest builds.
I can also have 1.0.0-LOCAL build (which is a local build on the developer's PC). I would like to force the maven to use the 1.0.0-LOCAL instead any other builds if it's available.
I don't know exactly how I could do these, maybe somehow with the settings.xml configuration file which is located on the build machine and on the developer's PC as well.
If I would have a any other way to do this please let me know.
Have a good day,
Arnold Robert Turdean
Update:
It turned out that the Maven Version Range - downloads all the available versions not just the latest one was the original problem.
Which maven version do you use? From Maven point of view all of those given versions are releases? The question is if it wouldn't be better to use a SNAPSHOT version instead?
Furthermore to check if the ordering of your artifacts is correct or work like you expect this can be checked by using this:
java -jar apache-maven-3.3.9\lib\maven-artifact-3.3.9.jar 1.0.0-12 1.0.0-9
Display parameters as parsed by Maven (in canonical form) and comparison result:
1. 1.0.0-12 == 1-12
1.0.0-12 > 1.0.0-9
2. 1.0.0-9 == 1-9
which shows correctly that 1.0.0-12 is greater than 1.0.0-9. So the question is also if you are using a repository manager etc. ? Do you do only a mvn install ?
What I don't understand is your statement about `1.0.0-LOCAL' ?
Apart from that I would suggest to prevent using of version ranges cause they make you build non reproducible.
In maven, dependency hierarchy is so important. Make sure that you don't have other dependencies which added before, into other pom's.
(In hierarchy, maven cares latest dependency.). Dependency 1.0.0-LOCAL must be the latest one.
I suggest to you, while the local developing time use generic -SNAPSHOT, use numbers when you start packaging .
I work on a big legacy project and I've noticed that in the project root pom we explicitly forced certain maven plugin versions.
I've read about the 'maven way' and it seems to me that this is a violation of this way - forcing versions instead of inheriting them from the superpom. Here's an example of what we have in the project pom:
<build>
<plugins>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.3.2</version>
<configuration>...</configuration>
</plugin>
My question is - what are the valid reasons (if any) to force plugin versions like that. I wonder because often times I find code that was written without any clear purpose and I do wonder if this is such a case, and if I should just drop the version from the project root pom.
Afterthought: On this site they say:
When declaring a "normal" version such as 3.8.2 for Junit, internally
this is represented as "allow anything, but prefer 3.8.2." This means
that when a conflict is detected, Maven is allowed to use the conflict
algorithms to choose the best version. If you specify [3.8.2], it
means that only 3.8.2 will be used and nothing else.
So this means, if you force the version to ensure stability, then you should also use [] otherwise maven is free to ignore your forced version.
The best is to define plugins versions only in a corporate pom and of course mainain this corporate pom over the time which means update the plugins versions from time to time.
This means in consequence that in no other project it is needed or better should be prevented to use a different versions of plugins (except there are very good reasons for this bugs in plugins).
Furthermore the excerpt you have given is an example of bad practice cause plugins and/or their configuration should be defined by using pluginManagement instead.
So if a project needs an older version of a maven plugin there should be at least a comment in the pom which describes why it's using not the inherited version. May be with a link to an appropriate JIRA issue...
what are the valid reasons (if any) to force plugin versions like that.
A valid reason is to keep a build repeatable, especially if there are known problems with a later version of the plugin. This ensures that the specific version is used, rather than a later version from an organisational parent pom (or, worse, from the default with no version specified anywhere).
I wonder because often times I find code that was written without any clear purpose and I do wonder if this is such a case
It's very possible, in a large code base, that this is exactly the case. The plugin configuration could have been copied from somewhere else and the version included without a good reason.
and if I should just drop the version from the project root pom.
If there is no reason given, either in a comment or a commit message, and if the same plugin has a version specified in the parent pom and if the build still works perfectly without it, then you should drop that version.
If it doesn't work, you should either fix the build or add a comment explaining exactly why this version is necessary.
As has already been stated, this can be because of corporate reasons - using new versions of plugins can break tests, functionality or even a whole product itself; new versions have to be tested thoroughly, advanced teams even need to discuss them because it can change the product in many ways.
Not forcing versions will create some kind of unstable situation during the next big build - which is always unwanted, developers dont like randomness :).
If your POM only describes a small, private project or maybe even a small community project you may very well let maven do all the version-management but thats pretty much a no-go for professional products which are worth .... say hundreds of thousands or even millions of currency units.
I am new to enterprise application developement and trying to create a REST server with Spring REST, JPA taking to mySQL database and Javascript on the client side. As I see loads of opensource libraries doing specific task, I started off with using 'maven project' with different 'arch type' (which is nothing but predefined POM with relevent libraries as I understand) provided by Eclipse. But I often run into version mismatch issues, in many cases found specific solution to that perticular libraries in StackOverflow or other sites.
Hence I started looking for a information these version dependancies such as, this version of JPA works with that version of Hibernate library and so on. I checked maven repository of major libraries, I did not find such information so far.
My queries are:
Where can I find these information about the versions dependancies?
Are these pre defined POM in eclipse reliable? Who owns them, where can I get last modified dates on these maven 'arch types'? (I find the ones I choose having fairly old version of libraries).
If I have to start off on my own creating a Maven dependacies, where will I get information about what are the dependent libraries, for example, if I need spring MVC, for sure it needs java servlet library. I am worried becuase the maven 'spring-mvc-jap' arch type whooping 50 libaries as dependancies.(Coming from embeded domain, I find to too hard to digest :D). So not sure if it is the right way.
Please correct if I am missing anything in my understanding.
You can find this information, if you are using maven and some IDE you can go to the dependancy and make click un > and this will show the librarys used for this dependancy or if you want to use the console you have http://maven.apache.org/plugins/maven-dependency-plugin/examples/resolving-conflicts-using-the-dependency-tree.html this will show the same that the IDE.
After normally in the documentation of the library used, you can find some doc about the dependancy about this.
Other solution is get the .jar and use 7zip to see the POM and know the dependancy used.
And for finish my answer if the IDE tell you that you dont have x dependancy normally you have to add this because any of the other dependancy used have it (they used only for the compiling task), but sometime somes projet change a lots of code between the version .a to .b so you will have some problem using the version .b, at this moment i didnt find one good and easy way to fix this, only using the way that i told you (only if i found some problem in the compilation)
3> I am not sure how it works in eclipse but in IntelliJ IDEA when you start using some class without proper dependency IDEA suggest you to add proper dependency automatically. The same approach should be in eclipse.
I'm writing an eclipse plugin. This plugin uses a few local jar files, and additionally has a few dependencies on other plugins.
I'm using the Google Code Search API from jar files, and it works fine; but after I add the plugin dependency org.eclipse.zest.dot.ui to my project, the Google Code Search API does no longer work - on calling new CodeSearchService("my_ID"), I'm getting the following run-time error:
Analysis failed: java.lang.NoSuchMethodError exception raised.
com.google.common.collect.ImmutableSet.buider()Lcom/google/common/collect/ImmutableSet$Builder;
I have carefully checked and reproduced this: if the plugin appears in the dependency list, the CodeSearchService can no longer be used; if it doesn't, it works perfectly. The actual project code does not change, only a dependency is added.
This is very strange to me, as I don't see how adding a plugin dependency should suddenly make some methods disappear. Has anyone encountered anything similar, and can share any insights about this problem and a possible solution? I'm not even sure if this issue is specific to these two libraries or not.
The org.eclipse.zest.dot.ui bundle pulls in dependencies that depend on the Google Collections, so my guess is that the Google Code Search API requires a different version of these, and is now trying to use the other version. Not sure how to solve this, but you could try to update both to the latest version (see http://wiki.eclipse.org/Zest#Zest_2.x for the newest org.eclipse.zest.dot.ui bundle).