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 :buildVampire
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