I am getting a 9.0 deprecation warning which I am stumped on how to fix. Apparently setting archiveFileName in a subprojects block will no longer be possible this way, but I don’t know what the alternative might be.
The warning is:
The org.gradle.api.plugins.BasePluginConvention type has been deprecated. This is scheduled to be removed in Gradle 9.0. Consult the upgrading guide for further information: Upgrading your build from Gradle 8.x to the latest
The warning’s line number indicates the “archiveFileName =” line near the end of this block:
task buildVersionFromFile (dependsOn: setupParameters) {
doLast {
// obtain and increment the build number
Properties props = new Properties()
File propsFile = new File("$buildNumberFile")
props.load(propsFile.newDataInputStream())
Integer nextBuildNum = ( ((props.getProperty("build")) as BigDecimal) + 1 )
props.setProperty("build", nextBuildNum.toString())
props.store(propsFile.newWriter(), null)
// put the two together to get the build number string
buildVersion = gitProjectBranch + "_" + nextBuildNum
buildType = gradle.taskGraph.hasTask(test) ? "RELEASE" : "SNAPSHOT"
// apply the version to all jars
subprojects {
jar{
manifest {
attributes 'Implementation-Version': buildVersion
}
archiveFileName = "positions_system_" + archivesBaseName + "_${buildVersion}_${buildType}.jar"
}
}
}
onlyIf {
buildNumberFile != null
}
}
Actually you have bigger problems.
Using subprojects { ... } at all is very bad practice and should be avoided and instead convention plugins used.
And configuring one task from the execution phase of another task within one project is bad practice and if you ever hope to use the fantastic configuration cache, you cannot do it anymore as it is forbidden with that.
Additionally, you do not even use task-configuration avoidance API, that saves you configuration time for tasks that are not run in the current invocation.
But to get rid of the warning, you could stop using the archivesBaseName property of that deprecated convention, but instead use the archiveBaseName property of the task.
Hi, thanks for the critique, although I don’t understand the issue with subprojects. The project has about 50 subprojects, and I need each to use the naming convention for its jar. I certainly don’t want to put that block of code into the gradle file of every subproject. I don’t know any other way to do that except by adding the subprojects block, and the build is blazing fast considering how much code is in this project. Certainly not a bigger problem.
I got the effect I needed as long as I add “.get()” to the end (which I guessed at). So thank you for that. No more deprecation warnings.
The usage of subprojets { ... } and allprojects { ... } is highly discouraged and legazy. It adds project coupling which works against more sophisticated Gradle features and optimizations and should be avoided. Besides that it makes builds less readable and less maintainable, as you for example cannot look at the build script of a project and can see what configuration is done or at least where configuration is coming from (for example by seeing a plugin that is applied where the logic is).
The alternative I already told you. The recommended and idiomatic way is to use [convention plugins}(Sharing Build Logic between Subprojects), for example implemented as precompiled script plugins in buildSrc or an included build to have almost the same syntax as you use in normal build scripts. Those convention plugins you then apply to the projects where you want their effect to be present.
