Slackbot
07/31/2023, 9:14 AMAdam
07/31/2023, 9:51 AM./gradle build
? Because that will trigger the ‘build’ task in all subprojects
Instead you could run the build task only in the specific subproject that you want to build, e.g.
./gradle :my-cool-subproject:build
Or if you want to run build only in the root project:
./gradle :build
Vampire
07/31/2023, 10:16 AMdistribution
plugin is registering the tar and zip tasks, but the start script generation is by the application
plugin.
Actually the question is, why you at all apply the application
plugin if you follow the imho horribly bad practice of building a fat jar. (see https://fatjar.net for some quotes)
If you build a fat jar, just do not apply the application
plugin and you also do not have the tasks you don't like.
Other than that, you cannot "disable a plugin" other than not applying it anyway. You can disable all tasks it registered, but just be disabling the tasks directly, they do not have a technical connection to the plugin, so there is no "disable all tasks of plugin X", as that would practically be the same as just not applying the plugin, just worse.Vampire
07/31/2023, 10:17 AMapplication
plugin and the distributable archive you get out of it and save the problems you will run into sooner or later by using fat jars which bring only problems and no actual added value.Luis Mirabal
07/31/2023, 10:19 AM./gradlew build
. I get your point of building each individual service, and that's what we want to achieve at some point but it's not currently possible. However, that would still run the mentioned tasksLuis Mirabal
07/31/2023, 10:21 AMVampire
07/31/2023, 10:28 AMenabled = false
on them, or you can exclude them using -x taskName
when calling Gradle which would also suppress tasks that are exclusively dependencies of that task and not required by something else in the build.Vampire
07/31/2023, 10:28 AMLuis Mirabal
07/31/2023, 10:32 AM