Develop Reference

DROOLS+ springboot+gradle

I have added the dependencies for drools in my build.gradle file.
implementation group: 'org.kie', name: 'kie-api', version: '7.16.0.Final'
implementation group: 'org.drools', name: 'drools-core', version: '7.16.0.Final'
implementation group: 'org.drools', name: 'drools-compiler', version: '7.16.0.Final'
implementation group: 'org.kie', name: 'kie-spring', version: '7.16.0.Final'
I can't understand the steps to proceed the project to write a rule in drools. please help me to know what should i do to write a rule in drools.(should i install plugins in drools and kie)

Gradle dependencies in JHipster format "groupId:artifact"

I am posting here to understand how does JHipster work with Gradle dependencies, in particular with regards to the fact that I am unable to copy some of them into a Gradle submodule I have created inside my JH project.
For example, the following doesn't work in a Gradle submodule
compile "junit:junit"
Error is
Could not resolve: junit:junit
However, the classic one copied from mvnrepository works great
compile group: 'junit', name: 'junit', version: '4.12'
Some additional information: I am creating a submodule that contains a set of classes related to testing, mainly a large load of custom Hamcrest matchers copied from another project from the Ant world. The original project had a lot of spaghetti code mess, so now I am refactoring into an isolated Gradle module. The testlib module shall depend on the testing frameworks and contain everything required for writing good tests. It can be compared to spring-test project you would use to write your own Spring-based tests.
At the moment, the gradle file looks like
plugins {
id "java"
}
configurations {
providedRuntime
implementation.exclude module: "spring-boot-starter-tomcat"
}
repositories {
mavenLocal()
mavenCentral()
jcenter()
}
group 'org.example' //different from com.acme of super-project
version '0.0.1-SNAPSHOT'
sourceCompatibility = 1.8
dependencies {
compile group: 'org.assertj', name: 'assertj-core', version: '3.13.2'
compile group: 'org.junit.jupiter', name: 'junit-jupiter-api', version: '5.5.2'
compile group: 'org.hamcrest', name: 'hamcrest', version: '2.1'
compile group: 'org.mockito', name: 'mockito-core', version: '3.0.0'
compile group: 'org.springframework.boot', name: 'spring-boot', version: spring_boot_version
compile "junit:junit" //Fails
}
Question
So the question is in two parts:
why does the scope "orgId:name" syntax work in the JHipster-generated module but not in submodules? Is it part of standard Gradle syntax?
why is that not working in a sub-module? Does JHipster apply a custom plugin to apply the correct version number that is clearly missing? How I do the same in a sub-module that is supposed to contain only Java library code?

With regards to JHipster, a little of more investigation helped. According to this answer, there is a trick in Gradle called Bill Of Materials project, so...
TL;DR
Add the following to the sub-project
// import JHipster dependencies BOM
implementation platform("io.github.jhipster:jhipster-dependencies:${jhipster_dependencies_version}")
So that the whole block looks like
dependencies {
// import JHipster dependencies BOM
implementation platform("io.github.jhipster:jhipster-dependencies:${jhipster_dependencies_version}")
compile "org.assertj:assertj-core"
compile "org.junit.jupiter:junit-jupiter-api"
compile "org.hamcrest:hamcrest"
compile "org.mockito:mockito-core"
compile "org.springframework.boot:spring-boot"
compile "junit:junit"
}
Long answer
Maybe in the future when I will understand Gradle more. Or just edit this answer 😁 to contribute

The bom defines the versions (besides other things) of 3rd party dependencies to be used so you can omit the explicit version. If you do not use the bom you can also write compile "junit:junit:4.12" but keep in mind jhipster uses already junit5 for all tests by default.
Regarding the import of the bom you can do it like you proposed or try to apply that dependency to all gradle subprojects in your main gradle file.

Gradle distZip - adds excluded dependency

My project uses
compile group: 'javax.servlet', name: 'javax.servlet-api', version: '3.1.0'
I added Google Sheets API to dependencies. Now
gradle dependencies says Google Sheets API uses org.mortbay.jetty:servlet-api:2.5-20081211 which I assume to exclude, because classes are loaded from the wrong jar:
compile (group: 'com.google.apis', name: 'google-api-services-sheets', version: 'v4-rev25-1.22.0') {
exclude(module: 'servlet-api')
}
compile (group: 'com.google.gdata', name: 'core', version: '1.47.1') {
exclude(module: 'servlet-api')
}
Now gradle dependencies does not show servlet-api:2.5 to be used anywhere. But after gradle clean distZip I see that archive contains servlet-api-2.5-20081211.jar! How can I exclude it from the build?

Exclude model from an included jar

gradle looks like:
dependencies{
compile files('libs/myJarContainingGuava.jar')
compile group: 'com.google.guava', name: 'guava', version: '18.0'
}
myJarContainingGuava has an old guava version in it.
My current code is picking that jar instead of picking the guava 18.
I cannot modify myJarContainingGuava.jar

How to specify a classifier in a gradle dependency's dependency?

Say I want to add guice-assistedinject as a dependency in my project. It specifies the guice artifact as a dependency itself. How do I tell it to use the no_aop version of guice?
I know I can do the following, but can I do it in one step without excluding the guice module?
dependencies {
compile (group: 'com.google.inject.extensions', name: 'guice-assistedinject', version: '3.0') {
exclude module: 'guice'
}
compile group: 'com.google.inject', name: 'guice', version: '3.0', classifier: 'no_aop'
}

There is no simpler solution. You can shorten the code by using short dependency notation (e.g. "com.google.inject:guice:3.0:no_aop").