Exclude resources from depenency library while generating fatJar

Help/Discuss
1

Fat Jar generation

I need a help with generating fatJar . I have the following code which generates the fatJar

jar {
	archiveFileName = 'myjar.jar'
  	zip64 = true
  	manifest {
    	attributes 'Main-Class': 'Main Class'
  	}
  
}

task fatJar(type: Jar) {
	manifest {
    	attributes 'Main-Class': 'Main Class'
  	}
  	duplicatesStrategy = DuplicatesStrategy.EXCLUDE
    archiveFileName = 'fat.jar'
    zip64 = true
    from { 
    	configurations.runtimeClasspath.collect {   
    		it.isDirectory() ? it :  zipTree(it)
    	}
    }
    with jar
    
    exclude 'META-INF/*.RSA'
    exclude 'META-INF/*.SF'
    exclude 'META-INF/*.DSA'
    exclude 'META-INF/*.txt'
}

The fatJar generation works fine. However I need help with excluding certain resource files. Currently if one if the included files has a resource matching with my resource file, the resource file from the library is getting included instead of my resource file. For eg: if there is a library xyz.jar with the following structure

xyz.jar file

src/main/java
	library class files
src/main/resources
	config.yaml

My project structure

src/main/java
	my class files
src/main/resources
	config.yaml

In this case the config.yaml file from xyz.jar file is getting included. But what I want is to have the file from my project to get included.

Kindly guide me on how to exclude the resource file from the included library and use my resource files.

2

This is one of the many reasons fat jars are bad. See https://fatjar.net/ for quotes on more reasons.
You probably need to add an exclude to the zipTree you are creating for the library so that the resources are not included there.

But I strongly recommend building a proper distributable archive using the application plugin instead.

Actually, when building a proper distribution, you can have the same or similar problem, as then it depends on classpath ordering which resource file is found. So having a plain config.yaml resource is often not a good idea and instead the libraries and also your application should better add some namespacing by placing the file inside a package unique to your code if possible.