Leave jar and war tasks enabled by default and differentiate their output locations from those of bootJar and bootWar by configuring them with a classifier

[novettaberin]

I cannot publish my spring boot jar to our maven repository (which is helpful when creating a package to go on our customer's private network) with the way the plugin operates now. I'm using the Spring Boot 2.1.17.RELEASE plugin due to some customer requirements at the moment. Bottom line is that I need to include this in my Gradle build script to make it work:

configurations {
    [apiElements, runtimeElements].each {
        it.outgoing.artifacts.removeIf { it.buildDependencies.getDependencies(null).contains(jar) }
        it.outgoing.artifact(bootJar)
    }
}

If your plugin did this for me, then our builds would work out of the box without failure. In fact your plugin would now do no harm to the expected behavior of Gradle.

[philwebb]

Can you elaborate some more on what those lines do and why you need them? Perhaps a sample project might help to show exactly the problem that you're facing.

[novettaberin]

Without those lines, when I type gradle publish I get an error saying there was nothing built--even when there was. The simple original jar needs to be removed from the list of artifacts (removeIf dependency is the Jar task), and the bootJar needs to be added to the artifact list.

[wilkinsona]

In fact your plugin would now do no harm to the expected behavior of Gradle.

I don't agree with this. While we disable the jar task by default, we have seen users that re-enable the task. In some cases, they are choosing to publish the normal jar while not publishing the artifact produced by bootJar. The change being proposed here would hinder this use case.

[wilkinsona]

Having discussed this with the Gradle team (thanks again, @jjohannes), the preferred solution is to have both jar and bootJar enabled, with one configured with a classifier so that their output does not clash. Ideally, we'd configure the jar task with a classifier so that the output of bootJar continues to be written to its current location but I'm not sure how possible that is. We'd need to experiment a bit.

We should also register the output of bootJar as an additional variant for publishing as part of the Java component. We'd use a separate configuration for this with no dependencies (as is appropriate for a fat jar where all of the dependencies are built in) and add the bootJar task to it as an artifact.