This message was deleted.
# community-supports
Slackbot
02/21/2022, 4:48 PMThis message was deleted.
l
Louis Jacomet
02/21/2022, 4:57 PMpublication is another aspect that matters in some cases.
a
Adrian Baker
02/21/2022, 8:23 PMI would say beyond just enforcement, it’s much easier to conceptually model and understand a large application that is split across multiple projects. Just as you split code across methods, classes and packages.
Adrian Baker
02/21/2022, 8:25 PMthis applies to both the Java code , but also the gradle aspects. For example, I normally have a subproject dedicated to the “main” class, plus the surrounding build logic to assemble the docker image. As well as splitting the Java code, it feels tidier to have this encapsulated in a separate gradle project, rather than one monolithic one (once it’s over a certain size)
z
Zak Taccardi
02/22/2022, 2:12 AMliterally because as soon as you need to deliver your application, or part of your code that makes up your application, in any flexible way - you need to have multiple projects. It helps with scaling too, as the project grows in size
In the same sense that single responsibility is valuable, so are multiple modules (subprojects)
t
Tom Gregory
02/22/2022, 8:53 AMGreat ideas. Thanks!
Tom Gregory
02/22/2022, 9:07 AM@Louis Jacomet do you mean when you want to publish a single artifact from each subproject?
l
Louis Jacomet
02/22/2022, 9:11 AMYes and also when your code grows and you start wondering if everything should be published in the same artifact. But maybe variants are not the right concept, etc …
j
Jendrik Johannes
02/23/2022, 7:15 AMWhen I give introduction to Gradle, I usually tell that Gradle first is a language which you may use to model your software (aka define the structure of or define the architecture of your software_)._ Then the Build Tool is a tool that reads this model to build the software (but other tools, like IntelliJ, read that model too).
I guess that’s your point “enforcing application layers” just expressed a bot more generic. And it’s also the point @Adrian Baker made.
Then you have:
1. Stronger modelling concept (e.g. compared to plain java packages) like “implementation” dependencies that enforce a certain encapsulation between the components of your software
2. Performance improvements (which you listed) that Gradle is able to offer due to this ‘rich’ model it has of the software