How do I customize the lib, lib-sources, AND lib-javadoc filenames?

Help/Discuss
1

The internet tells me I can customize the name of the library filename (for a gradle java-library project) by adding (to build.gradle.kts):

tasks.jar {
    archiveBaseName.set("foobar")
}

Works great. Good so far.

> ls lib/build/libs
foobar.jar

The internet also tells me I can generate a source-jar and a javadoc-jar like this (also in build.gradle.kts):

java {
    withSourcesJar()
    withJavadocJar()
}

Which is true, it does generate the assets. But they do not use the archiveBaseName for their filenames leaving me with:

> ls lib/build/libs
foobar.jar      lib-javadoc.jar       lib-sources.jar

How do I get all three lib filenames to “match”? I want:

foobar.jar      foobar-javadoc.jar       foobar-sources.jar

And while I’m at it, is there any way to have all three driven by the rootProject.name in the root gradle.settings file?

Ty!

Here’s a little more info on my project…

git init config choices:

Project type: library
Implementation language: kotlin
Build script DSL: kotlin
Project name: foobar
Source package: com.foobar
Java target version: 17
Generate build using new APIs and behavior? no

Gradle version

------------------------------------------------------------
Gradle 8.2.1
------------------------------------------------------------

Build time:   2023-07-10 12:12:35 UTC
Revision:     a38ec64d3c4612da9083cc506a1ccb212afeecaa

Kotlin:       1.8.20
Groovy:       3.0.17
Ant:          Apache Ant(TM) version 1.10.13 compiled on January 4 2023
JVM:          20.0.1 (Homebrew 20.0.1)
OS:           Mac OS X 12.6.2 aarch64
2

You should better not do that.
You can do

base {
    archivesName = "foobar"
}

which will then be effective on all three archive tasks.
But assuming you also want to publish this lib, it would still be published under the default coordinates, unless you then also change the publishing information.
And then you might have problems when you want to use that library in a composite build and then have to do a manual dependency substitution to make it work, and so on.

It would be much better to name the subproject itself foobar instead of lib and then everything just works as expected. Or if you do not need multiple subprojects, you can also remove the subproject and just do everything in the root project directly.

1 Like
3

Thank you @Vampire !!

I really appreciate the thorough response.

We just need a single standalone library. The default “multi-project” setup produced by gradle init (using the “library” project type) seems more complicated and burdensome that necessary for this common use-case.

Do you know… what’s the rational for the gradle init project template (for library) setting up as multi-project by default?

If I switch to “single project” (eliminate the subproject) are we giving up anything? (Like handy default-behavior such that we’d then need to do custom-config to achieve?)

My fear is that there’s a good reason gradle init sets up a multi-project by default, and that by switching to a single-project we’ll be missing out on some other important “default” behavior.

4

If you ask me, it is non-sense and I never do it like that.
The intention is, that you can easily add additional sibling projects later on if necessary without then needing to move the existing stuff from the root project down to a subproject to have it as sibling, not parent.
I personally prefer to do things in the root project, until I actually have a need for multiple sibling projects and if that need really arises, then I move it down then.

1 Like