I would like my Gradle build script to add the complete Classpath to the manifest file contained in JAR file created after the build.
Example:
Manife
I know this is likely trivial for the groovy people here, but in my case, I wanted to change the location of the Class-Path
in the manifest file depending on whether I was going to run in the production environment or local environment. I did this by making my build.gradle
's jar section look like this:
jar {
from configurations.runtime
manifest {
attributes ('Main-Class': 'com.me.Main',
'Class-Path': configurations.runtime.files.collect { jarDir+"/$it.name" }.join(' ')
)
}
}
In this case, the argument to gradle build
is passed like so:
$ gradle build -PjarDir="/opt/silly/path/"
Place this at the end of the buid.gradle
file. Change the com.example.Main
to your own Main class.
jar {
doFirst {
manifest {
if (!configurations.compile.isEmpty()) {
attributes(
'Class-Path': configurations.compile.collect{it.toURI().toString()}.join(' '),
'Main-Class': 'com.example.Main')
}
}
}
}
The top answers helped me a lot. Here is what worked for me:
jar {
manifest {
attributes "Main-Class": "your.package.classWithMain"
attributes "Class-Path": configurations.compile.collect { it.absolutePath }.join(" ")
}
}
So, instead of name, I had to use absolutePath. This may or may not work for you. Some suggest using runtime instead of compile. I used compile because, I have a compile section in dependencies in my build.gradle. So, the jar step picks up dependencies from there. The best thing to do is pick up something that you think will work, do a gradle build, then find the JAR file and expand it to find the META-INF/MANIFEST.MF file. You should be able to see all the directories separated by spaces. If not, you should try something different. Autocomplete feature of your IDE should be helpful in seeing what all methods or fields are available under configurations/compile etc. All this can be done easily in IntelliJ.
Oh.. and if you want to see where the library JARs are physically located on your disk, right click on your project->open module settings->Libraries and then click on any library.
Looks like gradle has evolved. This is another answer that looks similar to others, but there is a key difference: if you use a new keyword implementation
in the dependencies
, none of the other answers will work and you'll get an empty class path
dependencies {
// ensure the keyword here matches what
// you have in the jar->manifest->attributes
// that is "implementation"
implementation 'org.jetbrains.kotlinx:kotlinx-coroutines-core:1.3.3'
// ...
}
// by default, implementation cannot be referenced,
// this allows us to use it below
project.configurations.implementation.setCanBeResolved(true)
jar{
manifest {
attributes(
"Main-Class": "app.Program",
"Class-Path": configurations.implementation.collect { it.name }.join(' ')
)
}
dependsOn ('dependencies')
}
In the latest versions of gradle, compile
and runtime
becomes deprecated. Instead, use runtimeClasspath
as follows:
'Class-Path': configurations.runtimeClasspath.files.collect { it.getName() }.join(' ')
Note that if you are using Kotlin DSL, you can configure the manifest as follows:
configure<JavaPluginConvention> {
sourceCompatibility = JavaVersion.VERSION_1_8
targetCompatibility = JavaVersion.VERSION_1_8
manifest {
attributes(
"Manifest-Version" to "1.0",
"Main-Class" to "io.fouad.AppLauncher")
}
}
tasks.withType(Jar::class) {
manifest {
attributes["Manifest-Version"] = "1.0"
attributes["Main-Class"] = "io.fouad.AppLauncher"
}
}
I had a similar yet not identical problem. I was publishing my lib jar L in the artifactory, and later fetching it as a dependency of module M, but the transitive dependencies, the ones which L need for compile and runtime, did not arrive with it. It took me sometime to realize that my jar was published into the artifactory with an empty pom file, hence gradle was not able to know which are L's transitive dependencies to be fetched. The missing piece was an instruction, in the L's build.gradle, to publish the pom. As often with gradle, the connection between the name of the insturction, and its meaning, is completely:
apply plugin: 'maven'
uploadArchives {
repositories {
mavenDeployer {
repository(url: "file://localhost/tmp/myRepo/")
}
}
}
Source: uploading_to_maven_repositories