We Keep Coding

Gradle project does not export implementation-dependency to other projects

My gradle project contains 3 sub-projects with one source file each:
root-project\
sub-project-abstract\
...AbstractFoo.java
sub-project-commons\
...ConcreteFoo.java (extends AbstractFoo)
sub-project-main\
...Main.java (instantiates ConcreteFoo)
build.gradle of sub-project-commons:
dependencies {
implementation(project(:sub-project-abstract))
}
build.gradle of sub-project-main:
dependencies {
implementation(project(:sub-project-commons))
}
The Main-class in sub-project-main is aware of ConcreteFoo, however, compilation fails with cannot access AbstractFoo.
For some reason, I expected sub-project-commons to "export" ConcreteFoo and AbstractFoo, since it's a implementation-dependency. Or in other words, form the perspective of sub-project-main, AbstractFoo is a transitive dependency.
However, this doesn't seem to be the case.
I know that I could probably make it work by explicitly adding sub-project-abstract as a direct dependency to sub-project-main. However, that's something I want to avoid due to the nature of the commons project (my actual project contains up to 10 subprojects, and it should be possible to reuse the commons-project without declaring a dependency to sub-project-abstract every single time the commons-project is referenced.
Is there a way to make the Main-class aware of AbstractFoo without directly declaring sub-project-abstract as a dependency (but indirectly via sub-project-commons)?

This is expected behavior for the implementation configuration. You should apply the Java Library Plugin and use the api configuration.
The key difference between the standard Java plugin and the Java Library plugin is that the latter introduces the concept of an API exposed to consumers. A library is a Java component meant to be consumed by other components. It’s a very common use case in multi-project builds [emphasis added], but also as soon as you have external dependencies.
The plugin exposes two configurations that can be used to declare dependencies: api and implementation. The api configuration should be used to declare dependencies which are exported by the library API, whereas the implementation configuration should be used to declare dependencies which are internal to the component.
[...]
Dependencies appearing in the api configurations will be transitively exposed to consumers of the library, and as such will appear on the compile classpath of consumers. Dependencies found in the implementation configuration will, on the other hand, not be exposed to consumers, and therefore not leak into the consumers' compile classpath. [...]
In sub-project-commons (Kotlin DSL):
plugins {
...
`java-library`
}
...
dependencies {
api(project(":sub-project-abstract"))
}
...

exclude the configuration file (.xml and package) from dependency jar in gradle spring project

In my spring project we are using web dependency contains a configuration applicationContext.xml and security-config.xml. I have to change on both of them in my application how can I achieve this.
I'm expecting like this
compile (librariesdependencyname) {
exclude ('applicationContext.xml')
exclude ('common-security-config.xml')
}

If your team handling the jar. Just ask them to creating new version and without this configuration and resource files
OR
You can modify the context loader loaction and patter like below
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>classpath*:applicationContext.xml,classpath*:/**/*-config.xml</param-value>
</context-param>

More information about the project setup will help with more accurate suggestions.
There can be multiple way to achieve.
Assuming you have following
Library has mentioned xml files
We want the code not the configurations
As #Araf mentioned, we can request the team to update the library and change the configuration
Restructure the code to provide Autoconfigurations files this way consumer of library can choose to load the configurations through autoload or not
Define your own xml files to load so that it will not load library configurations
One way to achieve AutoConfiguration mechanism mentioned at https://docs.spring.io/spring-boot/docs/current/reference/html/features.html#features.developing-auto-configuration
or as it is your own project you can try multi module project https://www.baeldung.com/spring-boot-multiple-modules
Choosing which package to load or exclude, we can use #ComponentScan https://www.baeldung.com/spring-component-scanning.
XML version of annotations should be available, I personally prefer the annotations as it will use code as configurations.

You can add a custom task in gradle and instead of adding your jar compile "dependency. Define it as "something" dependency. Access it object using configurations."something" . Refer example below
librariesdependency "<<package-librariesdependencyname>>"
jar.dependsOn 'customJar'
task customJar (type: Jar) {
archiveName = 'your-output.jar'
from zipTree(configurations.librariesdependency.singleFile)
exclude 'applicationContext.xml'
}

Shared gradle project in spring boot does not contain yml files

I have projects A and B that both have common project as a compile dependency defined in their build.gradle files like this:
dependencies {
compile project(":common")
compile('org.springframework.boot:spring-boot-starter-actuator')
compile('org.springframework.boot:spring-boot-starter-web')
compile('org.springframework.boot:spring-boot-starter-security')
compile('org.springframework.boot:spring-boot-starter-cache')
compile("net.oauth.core:oauth:20090617")
compile("net.oauth.core:oauth-httpclient4:20090617")
compile('org.apache.httpcomponents:httpclient')
compile("com.atlassian.jira:jira-rest-java-client:2.0.0-m2")
compile("com.google.guava:guava:18.0")
compile('org.flywaydb:flyway-core')
testCompile('org.springframework.boot:spring-boot-starter-test')
}
This common project has application.yml file with all kind of common information such as database connection properties, hibernate setup, etc. So I do not want to duplicate these files all over the other projects such as A and B.
In project A the main spring boot file looks like this:
#SpringBootApplication(scanBasePackageClasses = {CommonApp.class,
A.class})
public class A {
public static void main(String[] args) {
SpringApplication.run(A.class, args);
}
}
where CommonApp is a main class in the commmon project. This common main file is the following:
#SpringBootApplication
public class CommonApp {
public static void main(String[] args) {
SpringApplication.run(CommonApp.class, args);
}
}
Projects A and B compile just fine, but all yml files that are in the classpath of the common project are not visible from A and B, so I have not choice but to duplicate them manually in A and B
What is the better approach? Can spring boot common projects share resources with other projects?
Notice that ideally solution should not be gradle dependant as I would like to run unit and integration tests from Intellij IDEA which does not use gradle for running tests.
My app structure is
app
|-A
|-build.gradle
|-web
|-B
|-build.gradle
|-common
|-src/main/resources
|-application.yml
|-database.yml
|-web.yml
|-settings.gradle
|-build.gradle
A, B and common are all spring boot apps (common is a boot app too, but it's only used as a dependency for A, B).

If you want a non-gradle solution, you could always add a DAO-esque file to access the required values in the common project then jar your common project and add it as a dependency to projects A and B.
Edit: I apologize, I did not explain very well. When I say "DAO-esque file", what I mean to say is a file of getter (and setters if needed) that access the properties file. For example, have a getter file that is a singleton. On creation, create a static reference to the property file. When Project A (or B) needs a property, it can call to this file to get the property.
As for a gradle solution, it looks like your above is fairly close with your
compile project(":common")
code. Do you have a settings.gradle file that has the line
includeFlat "common"
and a reference to the common project in the same directory as Project A and B? For example
Project A
(...Project A's files...)
Project B
(...Project B's files...)
Common
(...Common's files...)

In Gradle, associating task with a dependency configuration

How can a task be associated to a specific dependency configuration?
If I look the 23.5. Dependency management (gradle java plugin official doc) section part, it states that, for example, compileTestJava task use testCompile configuration.
I just wanted to know how I could achieve that.

gradle is creating these configurations automatically;
if you define a sourceSet, a bunch of things gets created (by convention):
sourceSets {
thing
}
will define configurations: thingCompile, thingRuntime
tasks: compileThingJava, processThingResources, thingClasses
you might want to look at: gradle tasks --all and gradle dependencies
if you want to add dependencies to these configurations
the most preferable to use the generated ones
you may of course create your own configuration and extend from that: configurations { thingCompile.extendsFrom(myConfig) }

Guice Multibinding from Classpath

I'm trying to setup a plugin system for cucumber-jvm bindings with Guice as DI. The idea is to run a beforeRequest() method before each When step in Cucumber. Plugins are separate .jar found in the classpath.
Since Cucumber requires an explicit Guice module declaration in cucumber.properties, that will be used to create an Injector, I can not use standard Guice Multibindings and have a separate Module per Plugin.
An idea how it should look like:
class CucumberClazz {
Set<Plugin> plugins;
public doRequest() {
for(Plugin plugin: plugins) plugin.beforeRequest();
/* Rest of the code */
}
}
Is there a fancy option to discover all implementations of Plugin in the classpath with Guice?