We've tried various approaches to using multiple seeders with UIMA Ruta but can't seem to find a method that works consistently.
We tried creating 2 separate Eclipse projects: one for each seeder. In this scenario, the Parameter Setting for our custom seeder gets overwritten with the default seeder class. This seems to happen randomly - we can't pin down a cause. Any ideas?
We also tried moving both seeders within the same aggregate engine in one Eclipse project (one Ruta AE for each script with the seeder class assigned on the AE). In this scenario it seems that, regardless of the order the scripts are executed, only the first seeder is being used. The second script runs with the first script's seeder. Any ideas on this?
We would love to hear how others have successfully managed to use multiple seeders. Thanks!
The multiple seeder functionality should work correctly. I just added a test here.
Please provide more information about the version and the build environement.
Trying to answer the question: I assume you use the simple ruta projects? Maybe you set the values in the generated analysis engine description, which will be overridden by using the template RutaEngine.xml. You need the perform the changes in that description. In case you use the ruta-maven-plugin, the same applies the configuration of the template.
DISCLAIMER: I am a developer of UIMA Ruta
Related
When writing a contract for an API i found myself repeating the same things over and over. For example regex validations for complex json object need to be copy pasted.
Thats tedious and not very DRY.
I'm using Kotlin DSL and Maven
I tried to extract the common parts in another file to reuse it. (Kotlin extension functions ftw.)
After trying multiple things to reuse that file I gave up.
The common parts should be as close to the actual contracts as possible. I don't want to export them in another project, and build them seperat, as they are an vital part of the contracts.
I tried it the following ways:
just put the file in the same directory and importing the functions, hoping it would be resolved as it would in java - did not work at all (my expectations were low, was worth a shot)
putting it in another maven module, and add that as dependency to the spring-cloud-contract-maven-plugin. that worked, as long as the dependant module was built and installed in the local maven repo. if no built version was available maven could not resolve it.
experimenting with kotlin script #file:Import() and #file:DependOn to tackle my issue, no luck.
Is there another way, that I missed? Is there a prefered way doing this?
This must be a common issue, right?
When we have spring-boot-devtools on pom.xml the drools rules dont work. There are no error but the drools rules dont get fired at all. After excluding the spring-boot-devtools the drools rule start working.
There's a documented issue about a classloading problem while using spring-boot devtools together with drools: DROOLS-1540
As specified in spring-boot reference documentation you can add jars to the devtools "reloading" classloader as a workaround.
META-INF/spring-devtools.properties
restart.include.drools-core=/drools-core-7.0.0.Final.jar
restart.include.drools-compiler=/drools-compiler-7.0.0.Final.jar
restart.include.kie-api=/kie-api-7.0.0.Final.jar
restart.include.kie-ci=/kie-ci-7.0.0.Final.jar
restart.include.kie-internal=/kie-internal-7.0.0.Final.jar
Be careful to use YOUR exacts jar and eventually add other libraries directly referenced in your rules files.
(for moderator) flgged Drools rule does't working in Spring Boot Controller but working in Junit Test as duplicated of this question and removed the answer on that post
Really strange problem indeed. As far as I can tell, there are 2 issues here:
Apparently, the KieFileSystem doesn't play well with org.springframework.boot.devtools.restart.classloader.RestartClassLoader. Even if I tried passing the DRL as a String, it didn't take it.
Even if I managed to get a populated KieBase using a kmodule.xml file, the rules were still not firing. My guess is that the classloader at some points changes the definition of the classes, so when you insert a Product object, its class is no longer the same as the Product class that is being used by the DRL. Another possibility is that there are multiple classloaders in play. Take a look at this question and at this document.
Unfortunately, I was not able to find a way to make it work. I hope the information I've provided helps you.
I am still very new in Cucumber-jvm/Selenium, so I am very sorry if the question sounds dumb.
My question is, if I run a feature file as a cucumber feature, do it run #before in different steps file because it search all the steps. If it does then how to make it just run the step I want? I can change the location of the glue code but is that the only solution?
Background: I'm an intern in a big company. I'm doing an automated software testing for a product. There is already an existing automated test steps. What we're going to do is to extend the project and add our own steps. I created a new simple steps class and feature file just to try it out. It doesn't work because every time I run the feature file, it triggers something which I presume #before in different steps. The #before is in every existing steps in the package. The thing work if I change package and do run configuration which I add the location of the glue code. I'm using Eclipse Photon.
Stepdefs and hook methods are global in nature ie. if they are present in the packages defined in the glue option of the runner they will be picked up for each scenario. The way out is to use tags on the hooks which match that on the scenario.
SOmething like
#Before("#TagNew")
#TagNew
Scenario:....
I'm trying to ignore Lombok code (generated code) from Sonar analysis based on files which have a custom annotation, #ExcludeLombok.
I've tried this guide which did not work.
In fact, I've even tried excluding an entire directory from analysis and it still wouldn't work.
I've also tirelessly searched through StackOverflow looking for a solution, and I've seen this has been discussed a good bit on here, but I've seen that people have been suggesting to write a single test to get the coverage up, which is pointless since we should not test auto generated code.
The solution I'm looking for is to exclude files based on a custom annotation.
But so far, anything I attempt to exclude does not get excluded.
Any help would be greatly appreciated.
There is currently no easy way to exclude issues raised by the SonarQube rules from the SonarQube Java Analyzer, except from using approaches described in the "Narrowing the focus" documentation you quote.
Now, we introduced recently the concept of issue filters in the SonarQube Java Analyzer. This mechanism is at the moment only used internally to exclude issues raised by rules at analysis time, based on specific criteria.
We plan to extends this mechanism in order to allow users to implements their own custom issue filters, the same way custom rules can be implemented. This approach would cover your case and allow you to filter any rules on code annotated with your custom annotation. This new feature will be handled in the following JIRA ticket: SONARJAVA-1761
Another option you have is to run Sonar over delomboked source. There are various ways to delombok depending on your build system see:
Delombok Overview.
For maven there's an example of running analysis on delomboked code: Delombok test pom
In each case you would make sure you ran the checks over generated source.
Ie. I have a GUI package, and a Logic package.
How can I prevent the Logic classes from importing GUI classes? Others(or myself) working on the same project might do that, which I want to prevent.
A solution could for example be a check in JUnit, that fails if its done, or a runtime check that throws an exception. Something along these lines, but how to do it?
You can write such a test using JDepend or DependencyFinder or Degraph.
Degraph is the only of the three tools that explicitly is intended to actually write tests for cases like this. Also AFAIK JDepend does not find all dependencies in more recent Java Versions (like classes mentioned in Annotations).
I'm the author of Degraph so I'm obivously biased.
I created the JabSaw project. It allows you to define modules by using annotated classes and to express the relationships between the modules. By default, a module contains all classes in a single package.The restrictions can be checked using a Maven plugin, from the command line or from a unit test. This should solve your problem.
One solution which comes to my mind is make GUI classes package private. Although you cannot isolate only one package and say, only Logic classes cannot use GUI, but other can.