What is the latest, greatest and best practice setup for build.gradle config?

I have some projects going live in the next week or so. Before this I want to upgrade the projects to latest build file and the up coming Enonic XP 5.2 platform.

So is there an best practice setup for build.gradle ?


I don’t know much about Gradle, but when using the gradle.build file from our recommended Skeleton Module, we get a lot of work done for us. Check it out, it does a lot of things with CSS and JS, minifying things and nice things like that. I’ll let somebody else explain more, but at least that’s a good start.

The nice part is with the CSS structure in the cms/assets/-folder you can have one Sass css file (scss) per Part and component (like one for all buttons) and then let Gradle handle the compressing. Check out this folder structure.

With Gradle installed just gradle watch or gradle deploy and that is all you need to remember =)

1 Like

Hi, I’ve asked our Gradle expert for input on this topic. The Skeleton module is a start, but we haven’t had the time or opportunity to create a best practice here yet, when it comes to structuring the Gradle build steps.

I noticed that gradle deploy sometimes does not copy over the jar file even if it’s changed. This is a bug that will be fixed in the next xp-gradle-plugin version.

Gradle is pretty flexible and can adapt for most situations. We could bundle some of the common usages into gradle “plugins” that you can apply insteaf of writing it yourself. I have some experimental code on this that I will discuss with @bwe and @tlo before sharing with everyone.