This message was deleted.

@Juan Fran Martín There are a lot of things that could be slowing your application build down. Grails 2 originally came out at the end of 2011, and has been EOL for over 2 years now. While I've been using Grails since 1.3.9, my memory of anything I would do in Grails 2 is fading. The upgrade from 2 to 3 can be difficult depending on how big your project is, and how many plugins you use that are no longer supported (a lot were replaced with features/gradle plugins, and some community-created plugins were never upgraded), and how many bad practices do you follow that are no longer supported. Grails 3 reprecented a rebase from Spring MVC and Gant(old build system) to SpringBoot and Gradle. After you get past Grails 3 upgrades become easier and I wouldn't bother upgrading incrementally and just upgrade to at least 5.3.x with a plan to upgrade to 6.0.x. Now upgrading depending on your project could actually make things worse. In the current project I'm working on that was the case because of how complex it is, because of the nature of the underlying Spring, and some ridiculously huge class files. Gradle the "newer" build system does have some tools that can help your build go faster, but it is very powerful and if you abuse that power it can bite you. While you can do multi-project builds in Gradle depending on how you do them they could cause longer build times because you have to build all of the projects. In my current project, it is so complex that it actually invalidates the cache of built projects. One idea might be if you can you could break parts of the app out that don't change a lot to plugins and precompile them, so they are just dependencies, Although that can make things more complex in other ways. Also because of the nature of Spring the more beans you have the longer it takes to wire everything up and the more memory it takes to get your application running. Grails 4 helped this a bit by making the main context based on Micronaut. If you have any class files that are bigger than 3k or 4k likes of code, if so refactor them, and break them up. That's all I can think about at the moment and I need to get to work myself, so good luck.

Containers are generally ephemeral, meaning they are created and destroyed at the end. This way, every time you run a test, a container is created that will download all the libraries, compile the project completely and finally run the tests. To improve this you will have to create volumes to store the libraries and not have to download them every time, it would also be interesting to create a volume to store the build directory so as not to have to fully compile the project.

True wasn't even thinking about the container aspect. It just amazes me how many projects I see come on here that are still on such old pre-Grails 3 versions of Grails.

Thanks @Groovy Duke, it's a legacy app and I think they follow a lot of bad practises before I came into the company. For example (i think this is a bad practise), to have more than one Config.groovy and more than one BuildConfig.groovy. I think every project should have only a Config.groovy and a BuildConfig.groovy Maybe some dependencies are collitioning with each other and the packaging takes more than expected.

Oh if those are the bad practices you have you haven't seen anything my favorites are: Doing Gorm calls and everything else in controllers instead of Services. Injecting services into domains. Having a class file that is 13k LOC long Having specific code per client and that code is just copied and pasted. Using inheritance with domain object and having 99 columns in one table for "custom" Fields. My current projects from a clean build take 8 to 12 minutes(3 to 5 for a restart) and that's on a Linux machine.

@Fernando henrique could you tell me which directories should I add to the volume? with adding only the

.grails

folder its ok? or you recommend me to add more?

You already mentioned that you are creating the volume for ~/.grails so you don't need to download the libraries again. Another directory is 'target' On the website https://grails.github.io/grails-howtos/en/performanceTuning.html it talks about jvm parameters -noverify -Xshare:off -Xms512M -Xmx512M -XX:MaxPermSize=256M -XX:PermSize=128M -XX:+UseParallelGC I believe that mainly noverify can help and adjusting the permsie too